Re: OCSP Connector on Tomcat 8.5 not working
Can I point certificateRevocationListFile= to an empty file so it always reverts to OCSP? From: Mark Thomas Sent: Friday, June 21, 2019 9:10 AM To: users@tomcat.apache.org Subject: Re: OCSP Connector on Tomcat 8.5 not working On 21/06/2019 16:46, Michael Magnuson wrote: > > > Thanks. Is that setup using a CRL instead of OCSP? It will work with either/both. I had a local OCSP responder running with OpenSSL so I could monitor the requests and responses. OCSP was working correctly. It rejected a cert that had been invalidated that wasn't in the CRL. Mark > > > From: Mark Thomas > Sent: Friday, June 21, 2019 8:44 AM > To: users@tomcat.apache.org > Subject: Re: OCSP Connector on Tomcat 8.5 not working > > On 21/06/2019 16:31, Michael Magnuson wrote: >> Hmm. It's still not working at all for me. Can you post your SSL connector >> configuration? > > protocol="org.apache.coyote.http11.Http11AprProtocol" >maxThreads="150" SSLEnabled="true" > > > caCertificateFile="conf/ca-rsa-cert.pem" > certificateRevocationListFile="conf/crl.pem"> > certificateFile="conf/localhost-rsa-cert.pem" > certificateChainFile="conf/localhost-rsa-chain.pem" > type="RSA" /> > > > > Mark > > >> >> >> >> >> From: Mark Thomas >> Sent: Thursday, June 20, 2019 11:36 AM >> To: users@tomcat.apache.org >> Subject: Re: OCSP Connector on Tomcat 8.5 not working >> >> On 20/06/2019 18:50, Mark Thomas wrote: >>> On 20/06/2019 18:27, Michael Magnuson wrote: Thanks Mark. A couple clarifications on your example first. You don't list the clientAuth= attribute. I assume this was a simple oversight. >>> >>> It is replaced by certificateVerification="required" >>> You list the SSLEnabled="true" attribute twice. Should one of these be secure="true"? >>> >>> It should. >>> For the certificateVerification= attribute, is the correct syntax "require" or "required"? >>> >>> "required" >>> >>> Setting up an OCSP responder locally is next on my TODO list. I'll >>> report back with the results. >> >> Works as expected. >> >> Mark >> >> >>> >>> Mark >>> >>> Thanks, Mike From: Mark Thomas Sent: Thursday, June 20, 2019 10:00 AM To: users@tomcat.apache.org Subject: Re: OCSP Connector on Tomcat 8.5 not working On 20/06/2019 17:24, Michael Magnuson wrote: > Mark, > > Thank you for your replies and help. > > I'm not sure how to verify that Tomcat Native was built with OCSP support? Lets assume it has been. I think that is a safe assumption for now. > Removing the element had no negative effect. I originally > put it in there following this guide: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomcat.apache.org%2Ftomcat-8.5-doc%2Fssl-howto.html%23Configuring_OCSP_Connector&data=02%7C01%7Cmmagnuson%40sempervalens.com%7C70a560314fd34bd2daae08d6f662f60d%7Cd2be4b7da12a4d0ab36310a94aadff1e%7C1%7C0%7C636967302246863617&sdata=yjo3dU%2B8NquIICb4qLJe42AOWjRpAqCilN2RSdjUlMw%3D&reserved=0 Hmm. We might need to revisit that. It looks "odd". > Without the trustStore attributes, it prompts for the smart card PIN and > you can select the cert you want to use, but then it doesn't do anything > from there. With those attributes present, Tomcat serves up the expected > page after PIN+cert. Interesting. That suggests Tomcat is using the trustStore to validate the client certs. I've looked at this again and the config is more mixed up that I first realised. Lets get that fixed first. > Changing clientAuth to "required" from "want" has no effect either way. OK. Lets leave it on required for now since that takes one variable out of the equation. Back to the config. I'm going to try and convert everything to the new style format. >>>protocol="org.apache.coyote.http11.Http11AprProtocol" maxThreads="150" SSLEnabled="true" scheme="https" SSLEnabled="true" >>>certificateVerification="required" caCertificateFile="path_to_ca_file"> >>> certificateKeyFile="path_to_server.key" certificateKeyPassword="password" certificateChainFile="path_to_chain" /> I have removed settings that are the same as the defaults. SSLCertificateChainFile isn't a recognised attribute. I opted for the OpenSSL style store for trusted CA certs. That probably means you need to export the trusted certs from your trustStoreFile to
Re: OCSP Connector on Tomcat 8.5 not working
On 21/06/2019 16:46, Michael Magnuson wrote: > > > Thanks. Is that setup using a CRL instead of OCSP? It will work with either/both. I had a local OCSP responder running with OpenSSL so I could monitor the requests and responses. OCSP was working correctly. It rejected a cert that had been invalidated that wasn't in the CRL. Mark > > > From: Mark Thomas > Sent: Friday, June 21, 2019 8:44 AM > To: users@tomcat.apache.org > Subject: Re: OCSP Connector on Tomcat 8.5 not working > > On 21/06/2019 16:31, Michael Magnuson wrote: >> Hmm. It's still not working at all for me. Can you post your SSL connector >> configuration? > > protocol="org.apache.coyote.http11.Http11AprProtocol" >maxThreads="150" SSLEnabled="true" > > > caCertificateFile="conf/ca-rsa-cert.pem" > certificateRevocationListFile="conf/crl.pem"> > certificateFile="conf/localhost-rsa-cert.pem" > certificateChainFile="conf/localhost-rsa-chain.pem" > type="RSA" /> > > > > Mark > > >> >> >> >> >> From: Mark Thomas >> Sent: Thursday, June 20, 2019 11:36 AM >> To: users@tomcat.apache.org >> Subject: Re: OCSP Connector on Tomcat 8.5 not working >> >> On 20/06/2019 18:50, Mark Thomas wrote: >>> On 20/06/2019 18:27, Michael Magnuson wrote: Thanks Mark. A couple clarifications on your example first. You don't list the clientAuth= attribute. I assume this was a simple oversight. >>> >>> It is replaced by certificateVerification="required" >>> You list the SSLEnabled="true" attribute twice. Should one of these be secure="true"? >>> >>> It should. >>> For the certificateVerification= attribute, is the correct syntax "require" or "required"? >>> >>> "required" >>> >>> Setting up an OCSP responder locally is next on my TODO list. I'll >>> report back with the results. >> >> Works as expected. >> >> Mark >> >> >>> >>> Mark >>> >>> Thanks, Mike From: Mark Thomas Sent: Thursday, June 20, 2019 10:00 AM To: users@tomcat.apache.org Subject: Re: OCSP Connector on Tomcat 8.5 not working On 20/06/2019 17:24, Michael Magnuson wrote: > Mark, > > Thank you for your replies and help. > > I'm not sure how to verify that Tomcat Native was built with OCSP support? Lets assume it has been. I think that is a safe assumption for now. > Removing the element had no negative effect. I originally > put it in there following this guide: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomcat.apache.org%2Ftomcat-8.5-doc%2Fssl-howto.html%23Configuring_OCSP_Connector&data=02%7C01%7Cmmagnuson%40sempervalens.com%7C410a86aa49c041d4c51208d6f65f5db1%7Cd2be4b7da12a4d0ab36310a94aadff1e%7C1%7C0%7C636967286823962847&sdata=h10h73IHgmzkRikvK%2B3AxcaGWf20PPbejYe8gt87Tcc%3D&reserved=0 Hmm. We might need to revisit that. It looks "odd". > Without the trustStore attributes, it prompts for the smart card PIN and > you can select the cert you want to use, but then it doesn't do anything > from there. With those attributes present, Tomcat serves up the expected > page after PIN+cert. Interesting. That suggests Tomcat is using the trustStore to validate the client certs. I've looked at this again and the config is more mixed up that I first realised. Lets get that fixed first. > Changing clientAuth to "required" from "want" has no effect either way. OK. Lets leave it on required for now since that takes one variable out of the equation. Back to the config. I'm going to try and convert everything to the new style format. >>>protocol="org.apache.coyote.http11.Http11AprProtocol" maxThreads="150" SSLEnabled="true" scheme="https" SSLEnabled="true" >>>certificateVerification="required" caCertificateFile="path_to_ca_file"> >>> certificateKeyFile="path_to_server.key" certificateKeyPassword="password" certificateChainFile="path_to_chain" /> I have removed settings that are the same as the defaults. SSLCertificateChainFile isn't a recognised attribute. I opted for the OpenSSL style store for trusted CA certs. That probably means you need to export the trusted certs from your trustStoreFile to a PEM encoded file for caCertificateFile. For the purposes of the test, you only need to export the cert that issued cert used by the client. I'm wondering if the slightly odd trust store config was causing problems. We r
Re: Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working
On 21/06/2019 13:48, Leonid Rozenblyum wrote: > Thank you! I've looked and the behaviour in 8.0.30 appears to be the same. The changes I was thinking of were a) much further back and b) unlikely to impact distributable. Mark > > On Fri, Jun 21, 2019 at 3:29 PM Mark Thomas wrote: > >> On 21/06/2019 12:39, Leonid Rozenblyum wrote: >>> Hi Mark! >>> Thanks for the explanation. >>> >>> So now it's mandatory for us to mark every web application >> >>> (and also ensure no dependencies in classpath are actual web fragments >>> without distributable accidentally) >>> >>> About our upgrade: >>> We've upgraded Tomcat >>> Tomcat 8.0.30 -> Tomcat 9.0.16 >>> (we are planning also the next update to Tomcat 9.0.21 to mitigate a >> https >>> issue but that's another story) >>> >>> In 8.0.30 just a in conf/web.xml has been enabled and >>> that caused DeltaManager working (was able to check by catalina logs and >> by >>> JMX manager and by the actual fact that session replication was working). >> >> Interesting. I'll need to go back and check what was going on there. >> There were some changes in that area as the Servlet EG clarified the >> expected behaviour for "plugability" features. I didn't think anything >> changed for distributable but it was a little while ago so I may have >> forgotten. >> >> I'll report back what I find. >> >> Mark >> >> >>> >>> On Fri, Jun 21, 2019 at 12:29 PM Mark Thomas wrote: >>> On 21/06/2019 09:54, Leonid Rozenblyum wrote: > Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager stopped > initializing. > StandardManager is used instead in cluster environment. Could you be more specific about version numbers please. > our global conf/web.xml contains as before. That is the default for conf/web.xml so it should not be necessary to set it. > I found a possible workaround: to copy the tag to the > web.xml in the web applications itself. That is expected. Web applications need to be explicitly marked as distributable. > However shouldn't it be inherited from the global conf/web.xml? No. For a web application to be distributable: - WEB-INF/web.xml needs to be marked as distributable - any web-fragment.xml files present in the web app need to be marked as distributable Internally, Tomcat creates additional web-fragment.xml files for JAR files that do not have one. These are marked as distributable by default to ensure they don't prevent the web app from being distributable. Internally, the global, host and tomcat specific web.xml files are also treated as fragments. They too are marked as distributable by default for the same reason. Tomcat creates these fragments internally as it allows us to re-use the web.xml merge code. > Is it a known behavior change? The process has been essentially the same from the early 8.0.x releases since that is where web-fragment.xml files were introduced. Mark - 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 >> >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OCSP Connector on Tomcat 8.5 not working
Thanks. Is that setup using a CRL instead of OCSP? From: Mark Thomas Sent: Friday, June 21, 2019 8:44 AM To: users@tomcat.apache.org Subject: Re: OCSP Connector on Tomcat 8.5 not working On 21/06/2019 16:31, Michael Magnuson wrote: > Hmm. It's still not working at all for me. Can you post your SSL connector > configuration? Mark > > > > > From: Mark Thomas > Sent: Thursday, June 20, 2019 11:36 AM > To: users@tomcat.apache.org > Subject: Re: OCSP Connector on Tomcat 8.5 not working > > On 20/06/2019 18:50, Mark Thomas wrote: >> On 20/06/2019 18:27, Michael Magnuson wrote: >>> Thanks Mark. A couple clarifications on your example first. You don't >>> list the clientAuth= attribute. I assume this was a simple oversight. >> >> It is replaced by certificateVerification="required" >> >>> You list the SSLEnabled="true" attribute twice. Should one of these be >>> secure="true"? >> >> It should. >> >>> For the certificateVerification= attribute, is the correct syntax >>> "require" or "required"? >> >> "required" >> >> Setting up an OCSP responder locally is next on my TODO list. I'll >> report back with the results. > > Works as expected. > > Mark > > >> >> Mark >> >> >>> >>> Thanks, >>> Mike >>> >>> >>> >>> >>> From: Mark Thomas >>> Sent: Thursday, June 20, 2019 10:00 AM >>> To: users@tomcat.apache.org >>> Subject: Re: OCSP Connector on Tomcat 8.5 not working >>> >>> On 20/06/2019 17:24, Michael Magnuson wrote: Mark, Thank you for your replies and help. I'm not sure how to verify that Tomcat Native was built with OCSP support? >>> >>> Lets assume it has been. I think that is a safe assumption for now. >>> Removing the element had no negative effect. I originally put it in there following this guide: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomcat.apache.org%2Ftomcat-8.5-doc%2Fssl-howto.html%23Configuring_OCSP_Connector&data=02%7C01%7Cmmagnuson%40sempervalens.com%7C410a86aa49c041d4c51208d6f65f5db1%7Cd2be4b7da12a4d0ab36310a94aadff1e%7C1%7C0%7C636967286823962847&sdata=h10h73IHgmzkRikvK%2B3AxcaGWf20PPbejYe8gt87Tcc%3D&reserved=0 >>> >>> Hmm. We might need to revisit that. It looks "odd". >>> Without the trustStore attributes, it prompts for the smart card PIN and you can select the cert you want to use, but then it doesn't do anything from there. With those attributes present, Tomcat serves up the expected page after PIN+cert. >>> >>> Interesting. That suggests Tomcat is using the trustStore to validate >>> the client certs. >>> >>> I've looked at this again and the config is more mixed up that I first >>> realised. Lets get that fixed first. >>> Changing clientAuth to "required" from "want" has no effect either way. >>> >>> OK. Lets leave it on required for now since that takes one variable out >>> of the equation. >>> >>> Back to the config. I'm going to try and convert everything to the new >>> style format. >>> >>> >>protocol="org.apache.coyote.http11.Http11AprProtocol" >>>maxThreads="150" >>>SSLEnabled="true" >>>scheme="https" >>>SSLEnabled="true" >>> >>certificateVerification="required" >>>caCertificateFile="path_to_ca_file"> >>> >> certificateKeyFile="path_to_server.key" >>> certificateKeyPassword="password" >>> certificateChainFile="path_to_chain" /> >>> >>> >>> >>> I have removed settings that are the same as the defaults. >>> SSLCertificateChainFile isn't a recognised attribute. >>> >>> I opted for the OpenSSL style store for trusted CA certs. That probably >>> means you need to export the trusted certs from your trustStoreFile to a >>> PEM encoded file for caCertificateFile. >>> >>> For the purposes of the test, you only need to export the cert that >>> issued cert used by the client. >>> >>> I'm wondering if the slightly odd trust store config was causing >>> problems. We really need more logging in Tomcat Native to figure that >>> sort of thing out. >>> >>> I also think I need to get OCSP working with client certs locally so I >>> can test it as well. I'll add that to my TODO list. >>> >>> Mark >>> >>> - >>> 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 >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomca
Re: OCSP Connector on Tomcat 8.5 not working
On 21/06/2019 16:31, Michael Magnuson wrote: > Hmm. It's still not working at all for me. Can you post your SSL connector > configuration? Mark > > > > > From: Mark Thomas > Sent: Thursday, June 20, 2019 11:36 AM > To: users@tomcat.apache.org > Subject: Re: OCSP Connector on Tomcat 8.5 not working > > On 20/06/2019 18:50, Mark Thomas wrote: >> On 20/06/2019 18:27, Michael Magnuson wrote: >>> Thanks Mark. A couple clarifications on your example first. You don't >>> list the clientAuth= attribute. I assume this was a simple oversight. >> >> It is replaced by certificateVerification="required" >> >>> You list the SSLEnabled="true" attribute twice. Should one of these be >>> secure="true"? >> >> It should. >> >>> For the certificateVerification= attribute, is the correct syntax >>> "require" or "required"? >> >> "required" >> >> Setting up an OCSP responder locally is next on my TODO list. I'll >> report back with the results. > > Works as expected. > > Mark > > >> >> Mark >> >> >>> >>> Thanks, >>> Mike >>> >>> >>> >>> >>> From: Mark Thomas >>> Sent: Thursday, June 20, 2019 10:00 AM >>> To: users@tomcat.apache.org >>> Subject: Re: OCSP Connector on Tomcat 8.5 not working >>> >>> On 20/06/2019 17:24, Michael Magnuson wrote: Mark, Thank you for your replies and help. I'm not sure how to verify that Tomcat Native was built with OCSP support? >>> >>> Lets assume it has been. I think that is a safe assumption for now. >>> Removing the element had no negative effect. I originally put it in there following this guide: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomcat.apache.org%2Ftomcat-8.5-doc%2Fssl-howto.html%23Configuring_OCSP_Connector&data=02%7C01%7Cmmagnuson%40sempervalens.com%7C0c191aa872024cbf07a708d6f5ae2ceb%7Cd2be4b7da12a4d0ab36310a94aadff1e%7C1%7C0%7C636966525783014430&sdata=gg7Xk9uuawyPhOt0q96e9gHsjsFVSdZSc2E0NPpWuHA%3D&reserved=0 >>> >>> Hmm. We might need to revisit that. It looks "odd". >>> Without the trustStore attributes, it prompts for the smart card PIN and you can select the cert you want to use, but then it doesn't do anything from there. With those attributes present, Tomcat serves up the expected page after PIN+cert. >>> >>> Interesting. That suggests Tomcat is using the trustStore to validate >>> the client certs. >>> >>> I've looked at this again and the config is more mixed up that I first >>> realised. Lets get that fixed first. >>> Changing clientAuth to "required" from "want" has no effect either way. >>> >>> OK. Lets leave it on required for now since that takes one variable out >>> of the equation. >>> >>> Back to the config. I'm going to try and convert everything to the new >>> style format. >>> >>> >>protocol="org.apache.coyote.http11.Http11AprProtocol" >>>maxThreads="150" >>>SSLEnabled="true" >>>scheme="https" >>>SSLEnabled="true" >>> >>certificateVerification="required" >>>caCertificateFile="path_to_ca_file"> >>> >> certificateKeyFile="path_to_server.key" >>> certificateKeyPassword="password" >>> certificateChainFile="path_to_chain" /> >>> >>> >>> >>> I have removed settings that are the same as the defaults. >>> SSLCertificateChainFile isn't a recognised attribute. >>> >>> I opted for the OpenSSL style store for trusted CA certs. That probably >>> means you need to export the trusted certs from your trustStoreFile to a >>> PEM encoded file for caCertificateFile. >>> >>> For the purposes of the test, you only need to export the cert that >>> issued cert used by the client. >>> >>> I'm wondering if the slightly odd trust store config was causing >>> problems. We really need more logging in Tomcat Native to figure that >>> sort of thing out. >>> >>> I also think I need to get OCSP working with client certs locally so I >>> can test it as well. I'll add that to my TODO list. >>> >>> Mark >>> >>> - >>> 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 >> > > > - > 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: OCSP Connector on Tomcat 8.5 not working
Hmm. It's still not working at all for me. Can you post your SSL connector configuration? From: Mark Thomas Sent: Thursday, June 20, 2019 11:36 AM To: users@tomcat.apache.org Subject: Re: OCSP Connector on Tomcat 8.5 not working On 20/06/2019 18:50, Mark Thomas wrote: > On 20/06/2019 18:27, Michael Magnuson wrote: >> Thanks Mark. A couple clarifications on your example first. You don't list >> the clientAuth= attribute. I assume this was a simple oversight. > > It is replaced by certificateVerification="required" > >> You list the SSLEnabled="true" attribute twice. Should one of these be >> secure="true"? > > It should. > >> For the certificateVerification= attribute, is the correct syntax "require" >> or "required"? > > "required" > > Setting up an OCSP responder locally is next on my TODO list. I'll > report back with the results. Works as expected. Mark > > Mark > > >> >> Thanks, >> Mike >> >> >> >> >> From: Mark Thomas >> Sent: Thursday, June 20, 2019 10:00 AM >> To: users@tomcat.apache.org >> Subject: Re: OCSP Connector on Tomcat 8.5 not working >> >> On 20/06/2019 17:24, Michael Magnuson wrote: >>> Mark, >>> >>> Thank you for your replies and help. >>> >>> I'm not sure how to verify that Tomcat Native was built with OCSP support? >> >> Lets assume it has been. I think that is a safe assumption for now. >> >>> Removing the element had no negative effect. I originally >>> put it in there following this guide: >>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomcat.apache.org%2Ftomcat-8.5-doc%2Fssl-howto.html%23Configuring_OCSP_Connector&data=02%7C01%7Cmmagnuson%40sempervalens.com%7C0c191aa872024cbf07a708d6f5ae2ceb%7Cd2be4b7da12a4d0ab36310a94aadff1e%7C1%7C0%7C636966525783014430&sdata=gg7Xk9uuawyPhOt0q96e9gHsjsFVSdZSc2E0NPpWuHA%3D&reserved=0 >> >> Hmm. We might need to revisit that. It looks "odd". >> >>> Without the trustStore attributes, it prompts for the smart card PIN and >>> you can select the cert you want to use, but then it doesn't do anything >>> from there. With those attributes present, Tomcat serves up the expected >>> page after PIN+cert. >> >> Interesting. That suggests Tomcat is using the trustStore to validate >> the client certs. >> >> I've looked at this again and the config is more mixed up that I first >> realised. Lets get that fixed first. >> >>> Changing clientAuth to "required" from "want" has no effect either way. >> >> OK. Lets leave it on required for now since that takes one variable out >> of the equation. >> >> Back to the config. I'm going to try and convert everything to the new >> style format. >> >> >protocol="org.apache.coyote.http11.Http11AprProtocol" >>maxThreads="150" >>SSLEnabled="true" >>scheme="https" >>SSLEnabled="true" >> >certificateVerification="required" >>caCertificateFile="path_to_ca_file"> >> > certificateKeyFile="path_to_server.key" >> certificateKeyPassword="password" >> certificateChainFile="path_to_chain" /> >> >> >> >> I have removed settings that are the same as the defaults. >> SSLCertificateChainFile isn't a recognised attribute. >> >> I opted for the OpenSSL style store for trusted CA certs. That probably >> means you need to export the trusted certs from your trustStoreFile to a >> PEM encoded file for caCertificateFile. >> >> For the purposes of the test, you only need to export the cert that >> issued cert used by the client. >> >> I'm wondering if the slightly odd trust store config was causing >> problems. We really need more logging in Tomcat Native to figure that >> sort of thing out. >> >> I also think I need to get OCSP working with client certs locally so I >> can test it as well. I'll add that to my TODO list. >> >> Mark >> >> - >> 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 > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Slow startup of webapps (e.g., manager) after migration
Am 2019-06-21 um 14:33 schrieb Mark Thomas: On 21/06/2019 13:13, Osipov, Michael wrote: Folks, we're migrating off old hosts to new ones, but remain at 8.5.x (.34 to .42 at the moment) and Java 8. Surprisingly, an empty Tomcat wih just manager installed takes way too long too start. More precisely, the Tomcat is fast, deploying manager app is horribly slow: That sounds like insufficient entropy. That was my first idea too... 2019-06-21T13:50:35.233 INFORMATION [deblndw024v.ad001.siemens.net-startStop-3] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/var/opt/tomcat-smartld/webapps/manager] has finished in [47,818] ms 2019-06-21T13:07:40.484 INFORMATION [deblndw024v.ad001.siemens.net-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/var/opt/tomcat-smartld/webapps/manager] has finished in [126,041] ms 2019-06-21T13:17:35.885 INFORMATION [deblndw024v.ad001.siemens.net-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/var/opt/tomcat-smartld/webapps/manager] has finished in [80,368] ms Which class do I need to set to FINEST to narrow down the cause? org.apache.catalina.startup.HostConfig.level = FINEST did not help. If nothing helps, I'd debug the Tomcat code. If it is happening per webapp then I'd take a look at SessionIdGeneratorBase but it should log a warning if it takes more than 100ms to start. A series of 3 thread dumps ~5s apart while the app is starting may also shed some light. I often find doing a diff between them very enlightening. I have now done the undeploy/redeploy at least 50 times, the line from SessionIdGeneratorBase never appeared in the log file and the issue seems to be non-deterministic after a container (HP-UX) restart now. Restarting the JVM process doesn't make a difference. I have the feeling that this might be related to the HP-UX container which ran for weeks now and had to be restarted due to the OpenSSL update. I will keep on eye on this and re-report when I am able to trace this properly. I do have the dumps, but they are pointless because the start takes mostly < 2000 ms now. Thanks for the pointers, Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working
Thank you! On Fri, Jun 21, 2019 at 3:29 PM Mark Thomas wrote: > On 21/06/2019 12:39, Leonid Rozenblyum wrote: > > Hi Mark! > > Thanks for the explanation. > > > > So now it's mandatory for us to mark every web application > > > (and also ensure no dependencies in classpath are actual web fragments > > without distributable accidentally) > > > > About our upgrade: > > We've upgraded Tomcat > > Tomcat 8.0.30 -> Tomcat 9.0.16 > > (we are planning also the next update to Tomcat 9.0.21 to mitigate a > https > > issue but that's another story) > > > > In 8.0.30 just a in conf/web.xml has been enabled and > > that caused DeltaManager working (was able to check by catalina logs and > by > > JMX manager and by the actual fact that session replication was working). > > Interesting. I'll need to go back and check what was going on there. > There were some changes in that area as the Servlet EG clarified the > expected behaviour for "plugability" features. I didn't think anything > changed for distributable but it was a little while ago so I may have > forgotten. > > I'll report back what I find. > > Mark > > > > > > On Fri, Jun 21, 2019 at 12:29 PM Mark Thomas wrote: > > > >> On 21/06/2019 09:54, Leonid Rozenblyum wrote: > >>> Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager stopped > >>> initializing. > >>> StandardManager is used instead in cluster environment. > >> > >> Could you be more specific about version numbers please. > >> > >>> our global conf/web.xml contains as before. > >> > >> That is the default for conf/web.xml so it should not be necessary to > >> set it. > >> > >>> I found a possible workaround: to copy the tag to the > >>> web.xml in the web applications itself. > >> > >> That is expected. Web applications need to be explicitly marked as > >> distributable. > >> > >>> However shouldn't it be inherited from the global conf/web.xml? > >> > >> No. For a web application to be distributable: > >> > >> - WEB-INF/web.xml needs to be marked as distributable > >> - any web-fragment.xml files present in the web app need to be marked as > >> distributable > >> > >> Internally, Tomcat creates additional web-fragment.xml files for JAR > >> files that do not have one. These are marked as distributable by default > >> to ensure they don't prevent the web app from being distributable. > >> > >> Internally, the global, host and tomcat specific web.xml files are also > >> treated as fragments. They too are marked as distributable by default > >> for the same reason. > >> > >> Tomcat creates these fragments internally as it allows us to re-use the > >> web.xml merge code. > >> > >>> Is it a known behavior change? > >> > >> The process has been essentially the same from the early 8.0.x releases > >> since that is where web-fragment.xml files were introduced. > >> > >> Mark > >> > >> - > >> 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: Slow startup of webapps (e.g., manager) after migration
On 21/06/2019 13:13, Osipov, Michael wrote: > Folks, > > we're migrating off old hosts to new ones, but remain at 8.5.x (.34 to > .42 at the moment) and Java 8. Surprisingly, an empty Tomcat wih just > manager installed takes way too long too start. More precisely, the > Tomcat is fast, deploying manager app is horribly slow: That sounds like insufficient entropy. >> 2019-06-21T13:50:35.233 INFORMATION >> [deblndw024v.ad001.siemens.net-startStop-3] >> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of >> web application directory [/var/opt/tomcat-smartld/webapps/manager] >> has finished in [47,818] ms >> 2019-06-21T13:07:40.484 INFORMATION >> [deblndw024v.ad001.siemens.net-startStop-1] >> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of >> web application directory [/var/opt/tomcat-smartld/webapps/manager] >> has finished in [126,041] ms >> 2019-06-21T13:17:35.885 INFORMATION >> [deblndw024v.ad001.siemens.net-startStop-1] >> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of >> web application directory [/var/opt/tomcat-smartld/webapps/manager] >> has finished in [80,368] ms > > Which class do I need to set to FINEST to narrow down the cause? >> org.apache.catalina.startup.HostConfig.level = FINEST > did not help. If nothing helps, I'd debug the Tomcat code. If it is happening per webapp then I'd take a look at SessionIdGeneratorBase but it should log a warning if it takes more than 100ms to start. A series of 3 thread dumps ~5s apart while the app is starting may also shed some light. I often find doing a diff between them very enlightening. Mark > Note: I haven't tried any of our own apps for now, but this slow > deployment gives me creeps. > > FWIW, I am running off: >> 2019-06-21T13:16:14.371 INFORMATION [main] >> org.apache.catalina.startup.VersionLoggerListener.log Server >> version: Apache Tomcat/8.5.42 >> 2019-06-21T13:16:14.376 INFORMATION [main] >> org.apache.catalina.startup.VersionLoggerListener.log Server >> built: Jun 4 2019 20:29:04 UTC >> 2019-06-21T13:16:14.377 INFORMATION [main] >> org.apache.catalina.startup.VersionLoggerListener.log Server >> number: 8.5.42.0 >> 2019-06-21T13:16:14.377 INFORMATION [main] >> org.apache.catalina.startup.VersionLoggerListener.log OS >> Name: HP-UX >> 2019-06-21T13:16:14.377 INFORMATION [main] >> org.apache.catalina.startup.VersionLoggerListener.log OS >> Version: B.11.31 >> 2019-06-21T13:16:14.377 INFORMATION [main] >> org.apache.catalina.startup.VersionLoggerListener.log >> Architecture: IA64N >> 2019-06-21T13:16:14.378 INFORMATION [main] >> org.apache.catalina.startup.VersionLoggerListener.log Java >> Home: /opt/java8/jre >> 2019-06-21T13:16:14.378 INFORMATION [main] >> org.apache.catalina.startup.VersionLoggerListener.log JVM >> Version: 1.8.0.17-hp-ux-b1 >> 2019-06-21T13:16:14.379 INFORMATION [main] >> org.apache.catalina.startup.VersionLoggerListener.log JVM >> Vendor: Hewlett Packard Enterprise Company >> 2019-06-21T13:16:14.386 INFORMATION [main] >> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded >> APR based Apache Tomcat Native library [1.2.21] using APR version >> [1.6.6]. >> 2019-06-21T13:16:14.386 INFORMATION [main] >> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR >> capabilities: IPv6 [true], sendfile [true], accept filters [false], >> random [true]. >> 2019-06-21T13:16:14.386 INFORMATION [main] >> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent >> APR/OpenSSL configuration: useAprConnector [true], useOpenSSL [true] >> 2019-06-21T13:16:14.401 INFORMATION [main] >> org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL >> successfully initialized [OpenSSL 1.0.2k 26 Jan 2017] > > I have compiled all native components myself, except for Java and > OpenSSL. They are provided by HPE in binary form. > Note: OpenSSL update to 1.0.2r is pending, but this should not be cause > here.> > Michael > > - > 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: Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working
On 21/06/2019 12:39, Leonid Rozenblyum wrote: > Hi Mark! > Thanks for the explanation. > > So now it's mandatory for us to mark every web application > (and also ensure no dependencies in classpath are actual web fragments > without distributable accidentally) > > About our upgrade: > We've upgraded Tomcat > Tomcat 8.0.30 -> Tomcat 9.0.16 > (we are planning also the next update to Tomcat 9.0.21 to mitigate a https > issue but that's another story) > > In 8.0.30 just a in conf/web.xml has been enabled and > that caused DeltaManager working (was able to check by catalina logs and by > JMX manager and by the actual fact that session replication was working). Interesting. I'll need to go back and check what was going on there. There were some changes in that area as the Servlet EG clarified the expected behaviour for "plugability" features. I didn't think anything changed for distributable but it was a little while ago so I may have forgotten. I'll report back what I find. Mark > > On Fri, Jun 21, 2019 at 12:29 PM Mark Thomas wrote: > >> On 21/06/2019 09:54, Leonid Rozenblyum wrote: >>> Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager stopped >>> initializing. >>> StandardManager is used instead in cluster environment. >> >> Could you be more specific about version numbers please. >> >>> our global conf/web.xml contains as before. >> >> That is the default for conf/web.xml so it should not be necessary to >> set it. >> >>> I found a possible workaround: to copy the tag to the >>> web.xml in the web applications itself. >> >> That is expected. Web applications need to be explicitly marked as >> distributable. >> >>> However shouldn't it be inherited from the global conf/web.xml? >> >> No. For a web application to be distributable: >> >> - WEB-INF/web.xml needs to be marked as distributable >> - any web-fragment.xml files present in the web app need to be marked as >> distributable >> >> Internally, Tomcat creates additional web-fragment.xml files for JAR >> files that do not have one. These are marked as distributable by default >> to ensure they don't prevent the web app from being distributable. >> >> Internally, the global, host and tomcat specific web.xml files are also >> treated as fragments. They too are marked as distributable by default >> for the same reason. >> >> Tomcat creates these fragments internally as it allows us to re-use the >> web.xml merge code. >> >>> Is it a known behavior change? >> >> The process has been essentially the same from the early 8.0.x releases >> since that is where web-fragment.xml files were introduced. >> >> Mark >> >> - >> 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
Slow startup of webapps (e.g., manager) after migration
Folks, we're migrating off old hosts to new ones, but remain at 8.5.x (.34 to .42 at the moment) and Java 8. Surprisingly, an empty Tomcat wih just manager installed takes way too long too start. More precisely, the Tomcat is fast, deploying manager app is horribly slow: 2019-06-21T13:50:35.233 INFORMATION [deblndw024v.ad001.siemens.net-startStop-3] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/var/opt/tomcat-smartld/webapps/manager] has finished in [47,818] ms 2019-06-21T13:07:40.484 INFORMATION [deblndw024v.ad001.siemens.net-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/var/opt/tomcat-smartld/webapps/manager] has finished in [126,041] ms 2019-06-21T13:17:35.885 INFORMATION [deblndw024v.ad001.siemens.net-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/var/opt/tomcat-smartld/webapps/manager] has finished in [80,368] ms Which class do I need to set to FINEST to narrow down the cause? > org.apache.catalina.startup.HostConfig.level = FINEST did not help. If nothing helps, I'd debug the Tomcat code. Note: I haven't tried any of our own apps for now, but this slow deployment gives me creeps. FWIW, I am running off: 2019-06-21T13:16:14.371 INFORMATION [main] org.apache.catalina.startup.VersionLoggerListener.log Server version: Apache Tomcat/8.5.42 2019-06-21T13:16:14.376 INFORMATION [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Jun 4 2019 20:29:04 UTC 2019-06-21T13:16:14.377 INFORMATION [main] org.apache.catalina.startup.VersionLoggerListener.log Server number: 8.5.42.0 2019-06-21T13:16:14.377 INFORMATION [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: HP-UX 2019-06-21T13:16:14.377 INFORMATION [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: B.11.31 2019-06-21T13:16:14.377 INFORMATION [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: IA64N 2019-06-21T13:16:14.378 INFORMATION [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /opt/java8/jre 2019-06-21T13:16:14.378 INFORMATION [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 1.8.0.17-hp-ux-b1 2019-06-21T13:16:14.379 INFORMATION [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Hewlett Packard Enterprise Company 2019-06-21T13:16:14.386 INFORMATION [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR based Apache Tomcat Native library [1.2.21] using APR version [1.6.6]. 2019-06-21T13:16:14.386 INFORMATION [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. 2019-06-21T13:16:14.386 INFORMATION [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL configuration: useAprConnector [true], useOpenSSL [true] 2019-06-21T13:16:14.401 INFORMATION [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.0.2k 26 Jan 2017] I have compiled all native components myself, except for Java and OpenSSL. They are provided by HPE in binary form. Note: OpenSSL update to 1.0.2r is pending, but this should not be cause here. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working
Hi Mark! Thanks for the explanation. So now it's mandatory for us to mark every web application (and also ensure no dependencies in classpath are actual web fragments without distributable accidentally) About our upgrade: We've upgraded Tomcat Tomcat 8.0.30 -> Tomcat 9.0.16 (we are planning also the next update to Tomcat 9.0.21 to mitigate a https issue but that's another story) In 8.0.30 just a in conf/web.xml has been enabled and that caused DeltaManager working (was able to check by catalina logs and by JMX manager and by the actual fact that session replication was working). On Fri, Jun 21, 2019 at 12:29 PM Mark Thomas wrote: > On 21/06/2019 09:54, Leonid Rozenblyum wrote: > > Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager stopped > > initializing. > > StandardManager is used instead in cluster environment. > > Could you be more specific about version numbers please. > > > our global conf/web.xml contains as before. > > That is the default for conf/web.xml so it should not be necessary to > set it. > > > I found a possible workaround: to copy the tag to the > > web.xml in the web applications itself. > > That is expected. Web applications need to be explicitly marked as > distributable. > > > However shouldn't it be inherited from the global conf/web.xml? > > No. For a web application to be distributable: > > - WEB-INF/web.xml needs to be marked as distributable > - any web-fragment.xml files present in the web app need to be marked as > distributable > > Internally, Tomcat creates additional web-fragment.xml files for JAR > files that do not have one. These are marked as distributable by default > to ensure they don't prevent the web app from being distributable. > > Internally, the global, host and tomcat specific web.xml files are also > treated as fragments. They too are marked as distributable by default > for the same reason. > > Tomcat creates these fragments internally as it allows us to re-use the > web.xml merge code. > > > Is it a known behavior change? > > The process has been essentially the same from the early 8.0.x releases > since that is where web-fragment.xml files were introduced. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: TC 9.0.21: ContextListener + Servlet app
On 21/06/2019 11:04, Tommy Pham wrote: > Thank you for the clarification and the heads up. I greatly appreciate it. > I've been thinking about different methods of approach and I think this is > better than servletPath + pathInfo: > > return getServletContext() == null ? null : getServletContext(). > getRealPath(getRequestURI().substring(getContextPath().length())); > > due to less conditional checks yielding better execution time and since I > can't see any condition that either requestURI or contextPath could be null: getRequestURI() is not normalized and is still encoded. You need decoded values for getRealPath(). getServletPath() and getPathInfo() are both normalized and decoded. The null checks are going to be a lot cheaper than the decoding. That said, it would be unusual for that timing difference to be significant. Most web applications seem to spend a lot of time doing "stuff". Also keep in mind that these can be security sensitive operations. If you aren't careful you'll open up directory traversal vulnerabilities. You want to use nanoTime to get a better idea of timings and you should repeat that operation many times. I usually start with 100,000 iterations and then adjust up/down until I have something that takes ~10s and then take the average. > As for the new method of getRealPath(), how does the web container knows > which is the correct one? getRealPath() takes whatever path is provided and returns whatever file, if any, is at that location relative to the web application root. In the case of the method I was proposing for ServletRequest it would do something like: getServletContext().getRealPath(getServletPath() + getPathInfo() == null ? "" : getPathInfo()) Keep in mind that not all web applications are deployed on a file system. If the web application is deployed as a WAR you'll get null back. Mark > Does it then check if the file actually exists > for both getRealPath() and getPathTranslated() and compare? Going forward > to have progress of my project, I'll have write to my own servlet to handle > static content instead of forwarding to TC's default servlet. On the > bright side, I think I can have stricter enforcement ie: "/css/*.css" > > Thanks, > Tommy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC 9.0.21: ContextListener + Servlet app
Hi Mark,
On Thu, Jun 20, 2019 at 11:57 PM Mark Thomas wrote:
> On 21/06/2019 03:21, Tommy Pham wrote:
> >
> >
> > After some further research, it appears the issue I'm encountering is
> known
> > since 2007 by IBM at least:
> >
> > https://www-01.ibm.com/support/docview.wss?uid=swg21259282
> >
> > While reviewing the JSR-369 history, at jcp.org, it seems that this is
> > since servlet spec 2.3, perhaps even earlier. Does anyone know if the
> > email spec-sub...@jcp.org is the correct email which I can submit a
> > proposal for updating the JSR-369?
>
> It isn't.
>
> The Java EE specs have moved to Eclipse and are in the process of
> re-branding to Jakarta EE. The process now is to raise an issue here:
>
> https://github.com/eclipse-ee4j/servlet-api
>
> However...
>
> > I think the section 3.6 of the servlet
> > spect should be changed from:
> >
> > "The getPathTranslated method computes the real path of the pathInfo of
> the
> > request."
> >
> > to:
> >
> > The getPathTranslated method computes the real path of the servletPath
> and
> > pathInfo of the request. If the pathInfo is not valid, then compute the
> real
> > path of the servletPath.
>
> Since I'm one of the folks who would respond to any such request, I can
> give you a heads up on the likely response.
>
> That is never going to happen. There are multiple reasons:
>
> 1. It would break backwards compatibility.
>
> 2. The purpose of getPathTranslated() is to map *just* the pathInfo to
> the file system. There are use cases that need this functionality.
>
> 3. You can use ServletContext.getRealPath(String path)
>
> > Since the requestURI is comprise of /contextPath/servletPath/pathInfo. I
> > think the above would be more accurate to translate the requested path
> to a
> > static file on the file system as I've seen by various cases, and
> possibly
> > IBM's too.
>
> What is more likely to be accepted (but no guarantees) is a new method
> on ServletRequest getRealPath() (note the lack of parameter) that calls
> ServletContext#getRealPath() with servletPath + pathInfo (with
> appropriate null handling).
>
> Mark
>
>
Thank you for the clarification and the heads up. I greatly appreciate it.
I've been thinking about different methods of approach and I think this is
better than servletPath + pathInfo:
return getServletContext() == null ? null : getServletContext().
getRealPath(getRequestURI().substring(getContextPath().length()));
due to less conditional checks yielding better execution time and since I
can't see any condition that either requestURI or contextPath could be null:
hsr = (HttpServletRequest) request;
String pt = null;
final long startTime1 = System.currentTimeMillis();
pt = getPathTranslatedR1();
final long endTime1 = System.currentTimeMillis();
logger.debug(String.format("Correction of PathTranslated R1: %s
ms %s", (endTime1 - startTime1), pt));
pt = null;
final long startTime2 = System.currentTimeMillis();
pt = getPathTranslatedR2();
final long endTime2 = System.currentTimeMillis();
logger.debug(String.format("Correction of PathTranslated R2: %s
ms %s", (endTime2 - startTime2), pt));
private String getPathTranslatedR1() {
if (hsr.getServletContext() != null) {
if (hsr.getServletPath() != null) {
if (hsr.getPathInfo() != null) {
return
hsr.getServletContext().getRealPath(hsr.getServletPath()
+ hsr.getPathInfo());
}
return hsr.getServletContext().
getRealPath(hsr.getServletPath());
}
return null;
}
return null;
}
private String getPathTranslatedR2() {
return hsr.getServletContext() == null ? null : hsr.
getServletContext().
getRealPath(hsr.getRequestURI().substring(hsr.getContextPath().length()));
}
Correction of PathTranslated R1: 1 ms
D:\apache-tomcat-9.0.21\webapps\erm-0.0.1-SNAPSHOT\css\jquery-ui\base\index.html
Correction of PathTranslated R2: 0 ms
D:\apache-tomcat-9.0.21\webapps\erm-0.0.1-SNAPSHOT\css\jquery-ui\base\index.html
As for the new method of getRealPath(), how does the web container knows
which is the correct one? Does it then check if the file actually exists
for both getRealPath() and getPathTranslated() and compare? Going forward
to have progress of my project, I'll have write to my own servlet to handle
static content instead of forwarding to TC's default servlet. On the
bright side, I think I can have stricter enforcement ie: "/css/*.css"
Thanks,
Tommy
Re: Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working
On 21/06/2019 09:54, Leonid Rozenblyum wrote: > Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager stopped > initializing. > StandardManager is used instead in cluster environment. Could you be more specific about version numbers please. > our global conf/web.xml contains as before. That is the default for conf/web.xml so it should not be necessary to set it. > I found a possible workaround: to copy the tag to the > web.xml in the web applications itself. That is expected. Web applications need to be explicitly marked as distributable. > However shouldn't it be inherited from the global conf/web.xml? No. For a web application to be distributable: - WEB-INF/web.xml needs to be marked as distributable - any web-fragment.xml files present in the web app need to be marked as distributable Internally, Tomcat creates additional web-fragment.xml files for JAR files that do not have one. These are marked as distributable by default to ensure they don't prevent the web app from being distributable. Internally, the global, host and tomcat specific web.xml files are also treated as fragments. They too are marked as distributable by default for the same reason. Tomcat creates these fragments internally as it allows us to re-use the web.xml merge code. > Is it a known behavior change? The process has been essentially the same from the early 8.0.x releases since that is where web-fragment.xml files were introduced. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working
Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager stopped initializing. StandardManager is used instead in cluster environment. our global conf/web.xml contains as before. I found a possible workaround: to copy the tag to the web.xml in the web applications itself. However shouldn't it be inherited from the global conf/web.xml? Is it a known behavior change?
