SSDLC Compliance
Hi, We have a cybersecurity requirement for all software. We would like to know whether Tomcat version 7.0.25 is developed and comply with Secure Software Development Life Cycle (SSDLC)? Regards Adrian Gan [This e-mail is confidential and may be privileged. If you are not the intended recipient, please kindly notify us immediately and delete the message from your system; please do not copy or use it for any purpose, nor disclose its contents to any other person. Thank you.] ---ST Electronics Group--- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reset a single mod_jk worker counter
Hi Chris, Am 05.12.2016 um 22:25 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, Ping. I'd really like to be able to do this. Is it currently possible? When locating this message to reply to it, I found essentially the same message posted by me back in May. :) Thanks, - -chris On 11/21/16 9:24 AM, Christopher Schultz wrote: All, When using the mod_jk status worker in read-write mode, you can edit a worker (or sub-worker for an lb worker) and adjust certain settings like the timeouts, lbfactor, etc. You can also reset the stats on the worker back to zero. I'm interested in resetting the "errors" stat but not the remaining stat s. Is that possible? No, not currently. Since long term stats IMHO mostly make sense when grabbing them regularly via some monitoring, what's bad about resetting the other stats as well, so that at least all numbers give a consistent view? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat listener not coming up - no stuck threads
On Sat, Dec 3, 2016 at 2:28 PM Mark Thomas wrote: > On 03/12/2016 17:39, John D. Ament wrote: > > Sorry missed a response.. > > > > On Sat, Dec 3, 2016 at 12:36 PM John D. Ament > > wrote: > > > >> On Wed, Nov 30, 2016 at 8:50 PM Christopher Schultz < > >> ch...@christopherschultz.net> wrote: > >> > > John, > > > > On 11/26/16 7:29 PM, John D. Ament wrote: > Hi, > > Looking for some external input. I've put together a simple > tomcat embedded instance designed to deploy an arbitrary set of > servlets, filters, etc. > > For some reason, when I run tests with Tomcat the server never > fully launches. I can see the port in use, but connections to the > server are not answered by the instance. When I debug the start > up, I see what appears to be a loop attempting to start services > that never returns, in LifecycleBase. > > > > So you see a busy-loop? What's the stack trace? > > > > > >> I am probably seeing a busy-loop, however I see no stack traces. > > Take a thread dump. > > Better, take 3 ~10s apart and compare. > > > Tomcat version? > > > > > > 8.5.8 and a few older ones, so 8.0.30 and 8.5.3 as well (that I can > recall > > recently) > > > > > > > Easiest way to reproduce it with this project is to clone > https://github.com/hammock-project/hammock/ and run a local build > (to get snapshots) and then run 'mvn clean install -Ptomcat-test' > from rest-resteasy (or spark or jersey). > > > > Er... sorry, I'm not going to do that, and it doesn't look like anyone > > else is going to do that, either. > > > > > > Its always worth a shot. > > > > > > > I'm sure there's something simple I'm over looking. > > > > I browsed your github repo for about 15 seconds until I realized that > > there are like 10k files and I'd never find the embedded driver > > without asking. So, where is it? > > > > Can you compare your driver with any of the many Tomcat test cases > > that launch an embedded server instance? Those test classes do exactly > > what it sounds like you are trying to do. > > > > > > Happily, can you point me to some of these test cases? > > Most of them under trunk/test > > This one has several variations: > > http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/connector/TestRequest.java?view=annotate > > > > On a related note, documentation for tomcat embedded is scarce. I > usually > > have to find it on non-apache channels. What would be the best way to > get > > a document page started, maybe linked off of > > http://tomcat.apache.org/tomcat-8.5-doc/index.html ? What repo contains > > your site? I'd be happy to provide some patches from my own learnings. > > The docs are taken from the releases so you need to start here: > > http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/ > > So I was able to identify my issue. It's not specifically a tomcat problem, but tomcat's bootstrapping makes it unique. one of the issues I've observed is that Tomcat's use of multithreading causes some thread deadlocking with some synchronized blocks. I was wondering if there's a way to turn that off? Make tomcat's bootstrap happen in the same thread as the original invocation? > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Connector bindOnInit=false not behaving as expected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 12/4/16 3:24 PM, Mark Thomas wrote: It looks like the ProtocolHandler is really the place where the TLS configuration is taking effect, and not the Connector, so I'm largely ignoring the Connector for now. Is that the right choice to make, here? > > It depends. What you actually need to do is swap out the > SSLContext. This is in the SSLHostConfigCertificate. It looks like the only place the SSLContext is actually set is from Nio(2?)Endpoint.bind(). So that means that, with the current Tomcat implementation, changing the SSLContext means an unbind() followed by a bind(). Do I have that correct? This would be for JSSE only... for OpenSSL/APR, I suspect it will be the same thing, but any change would have to take both into account. What I'd really like to be able to do is replace the SSLContext without dropping any in-flight requests, while new requests wait to be serviced until the new configuration was available. Something like this: 1. Stop processing incoming connections (e.g. still accept(), but don't handshake, yet... or at least stay bound to the port, but don't yet accept() and allow the TCP stack backlog to queue incoming connections) 2. Load the new TLS configuration 3. Resume accepting connections with the updated TLS configuration 4. Requests accepted before step #1 continue to use the configuration effective at the time I'm not sure how all that squares with that JSSE is willing to do. Once the TLS handshake occurs, presumably it means that the connection will continue to be valid until it's closed. If a connection as mentioned in #4 above is long-running, the old SSLContext etc. will be GC'd after the connection finally closes. If that assumption is not correct, I don't think any of the above is even possible. What probably is possible is pausing all incoming connections, waiting X ms for them to complete, then unbind(), then bind(). Client observation would be that the service seems to stall, then fail. Presumably, immediately re-trying would connect and get the new configuration. How difficult do you think it would be to implement such a "graceful" shutdown of the connector? It would be the same as "stop" except that it would first allow all in-flight requests to complete (with some reasonable timeout... say, as specified by a parameter to a gracefulShutdown(int) call?) and then, in the case of the bindOnInit="false", it would unbind(). That would allow a JMX client to say "shut down gracefully", waiting for an OK response (which would indicate that the connector had in fact shut down), then immediately request a "start" and the connector would come back up. At this point, I'd probably argue that we should add a "restart gracefully" to the list of JMX-callable actions which just does both of those calls on the server without a second HTTP roundtrip from the JMX client. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYRfJcAAoJEBzwKT+lPKRYYz4P/RiXs43l3pCXS5RmivlhaIg2 QSTq2Og50I8+qK6wuhpABp0VvwOI29JQ0M+Bg2jSMM7sFRpnH+Z6brPOKArMwrYz fBRgg0HfwFJQqAFk+wdXfoSNkbvHtsvZIhrrPcJGth9Tr/BHwDXHcmCKmScTCg93 ynyw6AWDzZ8SxU1YpKHYhBXb1Zbz4KDGcxBLDcRs6S4qmnNeu2JQfn7xQNImPZg0 yToctnzzH/SRG2rEoySyKMY+jpynreMw9jUOmdygJaGh1r3dv00yivu08Dv9/8MI yiQCq678sa0U5pUKTZtvhb00ZszmCZ56dJTC0u51nSTWOkrj+AmaBjmWIR1CUdMO qO2PhRsL/EnYDeEYORcLuJ1oa+J3GcxplgsU0PX09vVN+7TF7F3h0oUH34PvMyIJ hrLQv958nMevodkeDEgW5/nVV8WctXXUbSgKG4IFufwPh3paMmqsO+9ea8/vnXWN iAnijwgRun2Cwl2CrjPDu9isN5zoLQTlyYJnw+tOE4JYFjCpLVJ8ykTeRQs/fSDD qEuMIAT3+MrNTIMN8c5zBoGxTIouWRuXDetpSlaVm2Ln1R4TghdkBf+D4RdBiMhV ED08VnzghwbuG6VpdbFTjTThj5qEb+SLiQmM7rf9WF36s7Gatl4z1FyTJn7gtj2+ Uvwqqd0kXA/XFnpmttHA =qvTT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector bindOnInit=false not behaving as expected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 12/4/16 3:24 PM, Mark Thomas wrote: > On 04/12/2016 20:09, Christopher Schultz wrote: >> All, >> >> On 12/1/16 6:07 PM, Christopher Schultz wrote: >>> All, >> >>> On 12/1/16 5:59 PM, Christopher Schultz wrote: All, >> I'm trying to use JMX to do things with Tomcat Connectors and ProtocolHandlers. Specifically, I'd like to re-load the keystore (really certificate) used for an HTTPs connection. >> I'm currently using Tomcat 8.0.30 for my testing. >> It looks like the ProtocolHandler is really the place where the TLS configuration is taking effect, and not the Connector, so I'm largely ignoring the Connector for now. Is that the right choice to make, here? > > It depends. What you actually need to do is swap out the > SSLContext. This is in the SSLHostConfigCertificate. Yeah, I knew I really needed to swap-out the SSLContext. I wasn't sure how easy that would be, so I started out with what was possible with JMX . It seems that calling the pause()/resume() or stop()/start() on the ProtocolHandler have no effect on resetting the SSLServerSockeyFactory, which is what would be required to achieve my goals (update a certificate for a running Tomcat instance). > > You need new code to do this if you want to handle it smoothly. > Failing that, you need to trigger bind(). Which means: > bindOnInit=false start() stop() > > change TLS config > > stop() * drop existing connections, new connections fail here * > this is generally a Bad Thing (tm) start() > > new TLS config available I'll have to check again, but above I was talking about the protocol handler, not the Connector. I believe that bouncing the protocol handler does not reload the certificate, etc. I suspect I'll have to call init(). When I do this without specifying bindOnInit=false awful things happen. First, calling init() gets me an error on stdout that the address is already in use, and then it's basically not possible to restart the ProtocolHandler after that point: it's dead as far as I can tell, because you can't call start() or resume() without getting a whole bunch of errors. > > You can't just call any method you like. You have to respect the > standard Lifecycle state transitions even though Endpoint doesn't > enforce them (the Interface and supporting base classes are not > visible to the package. :) Yeah. I was just flailing about a bit, here. Does that sound like a problem to anyone? I would think that failure to call init() would leave the ProtocolHandler in an uninitialized state, but I'm wondering if trying to RE-initialize the ProtocolHandler should be something that won't damage a previously-initialized component. When trying to script these types of connections, having a non-destructive init() might be useful. > > This is not a problem. Ok. So, I set bindOnInit="false" which is documented[1] to unbind on "stop". When calling stop(), the port continues to be bound by Tomcat. Calling stop() and then start() throws a BindException. :( Destroying the ProtocolHandler also leaves the port still bound, and also (unsurprisingly) destroys the ProtocolHandler. > > That sounds like a possible problem but we have unit tests that > explicitly test this behaves as expected (TestXxxEndpoint) so a > Tomcat bug looks unlikely. I think this ended up being an error with the keystore itself which caused the connector to get itself into a stat from which it could not be resurrected. I'll repeat my observations with a bit more care and report back. I think there is in fact something here that could be improved. Stopping the Connector also does not release the port. :( Calling stop() and then start() also throws a BindException. >> At this point, I think I'm stuck. Is there a bug here? >> I'm going to upgrade to 8.0.latest and repeat my tests, just in case. >> >>> I updated to 8.0.39 and noticed that I had moved my keystore >>> out of the way temporarily and so the connector was failing at >>> some point looking for that. I'll be repeating my tests with >>> more attention to detail, but what I think I've noticed is that >>> there are certain errors which can occur that cause the >>> Connector to get itself into a bad state. >> >>> Specifically, I think that problems with the crypto setup >>> cause the connector to bind to the port, then fail and not >>> unbind. Any later attempt to re-start the Connector fails >>> because the port is still bound. >> >>> I think the connector should catch (some?) exceptions and >>> unbind the port in those cases when bindOnInit=false. >> >> Any comments on whether or not these items should be considered >> bugs? Specifically, uncaught exceptions which can prevent the >> connector from coming back up again? > > If you find a sequence where
Re: Reset a single mod_jk worker counter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, Ping. I'd really like to be able to do this. Is it currently possible? When locating this message to reply to it, I found essentially the same message posted by me back in May. :) Thanks, - -chris On 11/21/16 9:24 AM, Christopher Schultz wrote: > All, > > When using the mod_jk status worker in read-write mode, you can > edit a worker (or sub-worker for an lb worker) and adjust certain > settings like the timeouts, lbfactor, etc. You can also reset the > stats on the worker back to zero. > > I'm interested in resetting the "errors" stat but not the remaining > stat s. > > Is that possible? > > Thanks, -chris > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYRdtAAAoJEBzwKT+lPKRYedkP/3ZeSsV7zZbFgVrq46wuETp7 pNDLbm+DCyzy812H6Rplme/oKoTkNWlTPqm5BWPrcyhxTQVOtRQCVq3fTF8YCS0l ouvQJ0VPUm1+m2mLb2Ke0m5y+q/hCukH9O2bT05NOmjff30GGjEl39+o2HO3BRwe k5Iyr1NXNze34x5zMsMyicUW7K38/xt1pKLANdGH3k5eVMFMk0ZeWmpmr9SOK78S 52+v5t7Ge2oQHpC9qWkzqOAw2YAtMbrJM0RlFdEtNvh4JqTfnnaoRFRqItlhw6xm As+XWhrOgNSvGu22PnYOT10Gv7rPpYxr2J33aaBXyF4FhmaiD22EdpMTe4mKCZ5h bnxpBKpKC4Nv9Xcg7YaUWuXwuNDHWdJuFRf616btEYCPHTDHwBHEeXoiHC/aypio 1lCvWTU6XVvEiLSaV0mB5k4ZC/weOnu35GXSHG3HtMlJo9eBNHVyDOLpP1IM6FsO dLjlZaMf01zt6etIDQ3UICUTcy9mv/bLsgLo/03qhGdg94FvdmtRPLvq8uvGPGTH BfcBJN6jgD7iPGnCzq1d0MJ3/t4oNWePvHbJqp1fo/hWnUFfS4rR4S7pngxIr7I/ dnxNVOl0Q0o/mp3IkZYINhg1VSwDyqeyroD0VW1l6/9m8eziylgawDAsrm9PBjq1 pHWb6RIrYOCcC0AD1wpA =jgyA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Unable to get SSL working on Tomcat 8.5
On 05/12/2016 18:33, Jim Weill wrote: > > > On 12/5/2016 8:43 AM, Mark Thomas wrote: >> On 05/12/2016 16:13, Mark Thomas wrote: >>> On 01/12/2016 22:17, Jim Weill wrote: sslEnabledProtocols is now just protocols for one thing. And you have to put your certificate stuff in an sub-section to the connector now. >>> That should not be necessary. Tomcat should handle the conversion for >>> you under the hood. >>> >>> I've tested this with a JKS store but not a pkcs12 store. Let me see if >>> there is something extra we need to do in the pkcs12 case. >> Confirmed. This is working as expected. The following works with 8.0.x >> and 8.5.x. I've built both from trunk but there are no relevant changes >> since the last release of each. >> >> > protocol="org.apache.coyote.http11.Http11NioProtocol" >> maxThreads="150" >> SSLEnabled="true" >> scheme="https" >> secure="true" >> clientAuth="false" >> sslProtocol="TLS" >> keystoreFile="conf/localhost-rsa.p12" >> keystoreType="PKCS12" >> keyPass="changeit" /> >> >> Mark >> > > > So what might have changed with tomcat between 7.0 and 8.5 then? I > upgraded from 7.0 to 8.5 and had to do the separate SSLHostConfig > section and change to the more updated connector syntax when a single > connector string as shown above used to work. The auto-switching to use the OpenSSL encryption could be a factor. Although any error is likely to include OpenSSL support classes in the stack trace. Another possibility is alias handling although that also looks to be OpenSSL related. I've found at one case where a keystore with a single key/cert/chain fails. I'm currently working on a patch for that. It should make it into a release in the new year. Tracking down the root cause is likely to involve debugging both the TLS handshake and the TLS connector initialisation. If you are able to that, great. If not, if you can provide a sample configuration - including dummy keys, certs and chains - that fails that others can use to debug then that would very helpful. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Unable to get SSL working on Tomcat 8.5
On 12/5/2016 8:43 AM, Mark Thomas wrote: On 05/12/2016 16:13, Mark Thomas wrote: On 01/12/2016 22:17, Jim Weill wrote: sslEnabledProtocols is now just protocols for one thing. And you have to put your certificate stuff in an sub-section to the connector now. That should not be necessary. Tomcat should handle the conversion for you under the hood. I've tested this with a JKS store but not a pkcs12 store. Let me see if there is something extra we need to do in the pkcs12 case. Confirmed. This is working as expected. The following works with 8.0.x and 8.5.x. I've built both from trunk but there are no relevant changes since the last release of each. Mark So what might have changed with tomcat between 7.0 and 8.5 then? I upgraded from 7.0 to 8.5 and had to do the separate SSLHostConfig section and change to the more updated connector syntax when a single connector string as shown above used to work. jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat Realm/LDAP - userRoles and Organization Unit name for authenticated users
Hi Felix If isUserinRole has information to make determination to different component accesses in the application that would be sufficient - although, what I really need to know is what department or Organizational unit they belong to after authentication in order to give them specific page component accesses. Any help on this is appreciated. -Original Message- From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] Sent: Sunday, December 04, 2016 2:17 AM To: users@tomcat.apache.org Subject: Re: Tomcat Realm/LDAP - userRoles and Organization Unit name for authenticated users Am 04.12.2016 um 08:04 schrieb Taylor, Larry: > Hello, > > For Users that have authenticated from the Web Login page through Tomcat > Realm LDAP configuration is it possible to get the authenticated user's > ou=Organizational Unit or Department name? and also what their role names > are? I need this information to pass to a servlet or jsp page. > > I saw documentation about the java.security.Principal class but could not > find any documentation or examples on how to get this type of information > after users are authenticated. > > I am able to get the username with ${pageContext.request.userPrincipal.name} > & request.getRemoteUser(); but nothing about how to get the user's member > affiliations and roles. The standard way to get the roles is to iterate over your expected roles and ask for request.isUserInRole(role). The servlet spec has no API to get directly a list of roles. If you are willing to bind yourself to the implementation of JNDIRealm you could get the list of roles. But I don't recommend it, as that implementation is not guaranteed to stay stable. Do you really need to get the list, or is isUserInRole enough? Regards, Felix > > Any information or pointers on this is appreciated. > > > > Larry Taylor > > - 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: Unable to get SSL working on Tomcat 8.5
On 05/12/2016 16:13, Mark Thomas wrote: > On 01/12/2016 22:17, Jim Weill wrote: >> sslEnabledProtocols is now just protocols for one thing. And you have to >> put your certificate stuff in an sub-section to the >> connector now. > > That should not be necessary. Tomcat should handle the conversion for > you under the hood. > > I've tested this with a JKS store but not a pkcs12 store. Let me see if > there is something extra we need to do in the pkcs12 case. Confirmed. This is working as expected. The following works with 8.0.x and 8.5.x. I've built both from trunk but there are no relevant changes since the last release of each. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Unable to get SSL working on Tomcat 8.5
It's working for me with the configuration attributes apart from your configuration : sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation". keystoreFile="certificate path" in the element. I couldn't succeed with the element -- Ram. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, December 05, 2016 10:14 AM To: Tomcat Users List Subject: Re: Unable to get SSL working on Tomcat 8.5 ** This mail has been sent from an external source ** On 01/12/2016 22:17, Jim Weill wrote: > sslEnabledProtocols is now just protocols for one thing. And you have > to put your certificate stuff in an sub-section to the > connector now. That should not be necessary. Tomcat should handle the conversion for you under the hood. I've tested this with a JKS store but not a pkcs12 store. Let me see if there is something extra we need to do in the pkcs12 case. Mark > Here's how ours had to be reconfigured (on 8443 instead of 443) using > NIO and JSSE: > > protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" > SSLEnabled="true" protocols="TLSv1.2"> > > certificateKeyFile="path-to-cert-keyfile" /> > > > > Hope this helps. The parts that are relevant to your certificate are > in the section here: > https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_ > -_SSLHostConfig but scroll up slightly to get the instructions on how > to use this subsection. > > jim > > On 12/1/2016 1:26 PM, Bartlett, Todd wrote: >> Thanks for your reply, unfortunately I know very little about Tomcat >> beyond the server.xml config below. >> What are "hooks" and or whats been deprecated related to the below, >> or is there a new example config for using a .pfx Keystorefile? >> >> > protocol="HTTP/1.1" >> SSLEnabled="true" >> maxThreads="150" >> scheme="https" >> secure="true" >> keystoreFile="C:\.pfx" >> keystorePass="" >> keystoreType="pkcs12" >> clientAuth="false" >> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" ciphers="..." /> >> >> -Original Message- >> From: Jim Weill [mailto:moon...@icsi.berkeley.edu] >> Sent: Thursday, December 01, 2016 2:38 PM >> To: Tomcat Users List >> Subject: Re: Unable to get SSL working on Tomcat 8.5 >> >> Are you using the 8.5 reference? >> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html >> >> When we updated to 8.5, we also found things changed with the >> connector for SSL. The above page is the current guide, and you'll >> notice several of the hooks have been deprecated since 6.0 >> >> jim >> >> On 12/1/2016 11:28 AM, Bartlett, Todd wrote: >>> Thanks for replying, some more information. >>> >>> Tomcat 8.0 works fine with this configuration (Ive tested both >>> installs on same server, same .pfx) (note no other changes anywhere, >>> just a fresh install and modifying the server.xml) We have been >>> using this config since 6.0 through 8.0. >>> >>> Something changed in 8.5, it does not seem to recognize or load the >>> .pfx file anymore. >>> >>> Thanks >>> >>> Todd >>> >>> -Original Message- >>> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >>> Sent: Wednesday, November 30, 2016 8:52 PM >>> To: Tomcat Users List >>> Subject: Re: Unable to get SSL working on Tomcat 8.5 >>> > Todd, > > On 11/29/16 4:41 PM, Bartlett, Todd wrote: > The below settings work fine on 6.0 version (no other changes Im > aware > of) Error received Failed to initialize component > [Connector[HTTP/1.1-443 > What's the rest of the error message? > > maxThreads="150" scheme="https" secure="true" > keystoreFile="C:\.pfx" keystorePass="" > keystoreType="pkcs12" clientAuth="false" > sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" ciphers="..." /> > Looks okay so far. You need to post more information. > > -chris >>> >>> >>> - 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 >> >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -
Re: Unable to get SSL working on Tomcat 8.5
On 01/12/2016 22:17, Jim Weill wrote: > sslEnabledProtocols is now just protocols for one thing. And you have to > put your certificate stuff in an sub-section to the > connector now. That should not be necessary. Tomcat should handle the conversion for you under the hood. I've tested this with a JKS store but not a pkcs12 store. Let me see if there is something extra we need to do in the pkcs12 case. Mark > Here's how ours had to be reconfigured (on 8443 instead > of 443) using NIO and JSSE: > > protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" > SSLEnabled="true" protocols="TLSv1.2"> > > certificateKeyFile="path-to-cert-keyfile" /> > > > > Hope this helps. The parts that are relevant to your certificate are in > the section here: > https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_SSLHostConfig > but scroll up slightly to get the instructions on how to use this > subsection. > > jim > > On 12/1/2016 1:26 PM, Bartlett, Todd wrote: >> Thanks for your reply, unfortunately I know very little about Tomcat >> beyond the server.xml config below. >> What are "hooks" and or whats been deprecated related to the below, or >> is there a new example config for using a .pfx Keystorefile? >> >> > protocol="HTTP/1.1" >> SSLEnabled="true" >> maxThreads="150" >> scheme="https" >> secure="true" >> keystoreFile="C:\.pfx" >> keystorePass="" >> keystoreType="pkcs12" >> clientAuth="false" >> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" ciphers="..." /> >> >> -Original Message- >> From: Jim Weill [mailto:moon...@icsi.berkeley.edu] >> Sent: Thursday, December 01, 2016 2:38 PM >> To: Tomcat Users List >> Subject: Re: Unable to get SSL working on Tomcat 8.5 >> >> Are you using the 8.5 reference? >> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html >> >> When we updated to 8.5, we also found things changed with the >> connector for SSL. The above page is the current guide, and you'll >> notice several of the hooks have been deprecated since 6.0 >> >> jim >> >> On 12/1/2016 11:28 AM, Bartlett, Todd wrote: >>> Thanks for replying, some more information. >>> >>> Tomcat 8.0 works fine with this configuration (Ive tested both >>> installs on same server, same .pfx) (note no other changes anywhere, >>> just a fresh install and modifying the server.xml) We have been using >>> this config since 6.0 through 8.0. >>> >>> Something changed in 8.5, it does not seem to recognize or load the >>> .pfx file anymore. >>> >>> Thanks >>> >>> Todd >>> >>> -Original Message- >>> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >>> Sent: Wednesday, November 30, 2016 8:52 PM >>> To: Tomcat Users List >>> Subject: Re: Unable to get SSL working on Tomcat 8.5 >>> > Todd, > > On 11/29/16 4:41 PM, Bartlett, Todd wrote: > The below settings work fine on 6.0 version (no other changes Im > aware > of) Error received Failed to initialize component > [Connector[HTTP/1.1-443 > What's the rest of the error message? > > maxThreads="150" scheme="https" secure="true" > keystoreFile="C:\.pfx" keystorePass="" > keystoreType="pkcs12" clientAuth="false" > sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" ciphers="..." /> > Looks okay so far. You need to post more information. > > -chris >>> >>> - >>> 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 >> >> > > > > - > 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: Thread-safety of javax.servlet.Servlet#getServletConfig()
On 12/5/2016 7:40 AM, Péter Gergely Horváth wrote: Hi Chris, Thanks your four input: this question is somewhere in-between... :) We have *definitely* seen cases, where a piece of code like the one below sometimes (a couple of times from tens of thousands of successfully serviced requests) found the stored field to be null - with a NullPointerException being thrown on the first access of the fooBarService field. @WebServlet("/open") public class FooBarServlet extends HttpServlet { private FooBarService fooBarService; @Override public void init() throws ServletException { try { ApplicationContext applicationContext = (ApplicationContext) getServletContext().getAttribute("springContext"); fooBarService = applicationContext.getBean("fooBarService", FooBarService.class); } catch (Exception ex) { // wrap any exceptions to ServletException so as to comply with Servlet contract throw new ServletException("Initialization failed with exception", ex); Does this exception ever occur? -Terence Bandoian } } protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { processRequest(request, response); } protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { processRequest(request, response); } private void processRequest(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { List = fooBarService.getFooBars(); /// we have seen NPEs thrown from here /// ... } For the first glance, it seemed to be obvious that it must have been a threading issue, which could easily be solved by adding volatile to the stored fooBarService field. However, I was more than confused seeing that javax.servlet.GenericServlet#config uses the same approach by simply storing the ServletConfig into a field and reading it later on without any locking etc. I quickly scanned through the Servlet specs and Catalina codes, but cannot really locate any explicit reference to thread-safety of javax.servlet.GenericServlet#getServletConfig, that is where the question originates. I would by much obliged if you had any inputs, ideas regarding this, or on the approach one could take to confirm it on his/her own. Thanks, Peter On Mon, Nov 28, 2016 at 6:45 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Péter, On 11/28/16 11:01 AM, Péter Gergely Horváth wrote: Thank you very much for your feedback, but I think there is a slight misunderstanding here: I know the order in which a servlet is initialized and put into service, and this question is not related to that. It's related to the _visibility_ of the field. The question is about the thread safety of the field access: if you carefully check the details of javax.servlet.GenericServlet#config and compare the implementation to the sample "NoVisibility" from the book Java Concurrency in Practice, then it is seems to follow the same pattern, which is "not thread-safe because the value field is accessed from both get and set without synchronization. Among other hazards, it is susceptible to stale values: if one thread calls set, other threads calling get may or may not see that update." [1]. Personally, I would like to understand why this implementation is not (if not) susceptible to the stale values phenomenon [2]; there might be someone, who can point me to the right direction. I think you are correct that there is a theoretical multi-threaded race-condition, here. The container may initialize the servlet in one thread and service e.g. the first request in another thread, and the ServletContext reference might not be written to main memory and then read-back by the request-processing thread. Potential fixes for this would be either to define the ServletContext member to be volatile or to use synchronized methods.' Adding synchronization to the init() method would not be a problem at all: there is very little monitor contention at that stage and the container would only expect to call that method a single time. Adding synchronization to the getServletContext method, though, might represent a reduction in performance, since getServletContext gets called many times during the lifetime of a Servlet, and from many thread s. Likewise, marking the ServletContext member as "volatile" would necessarily require a slow main-memory read every time getServletContext is called. I suspect simple analysis above is the reason for no multithreaded protection being placed on the ServletContext member in question. Péter, is this an academic discussion, or have you in fact seen a case where a servlet has been initialized and yet the first thread to process a request receives a null val
AW: log4j2 configuration in Tomcat 8.5.8
OK Rainer i moved log4j-core-2.6.2.jar, log4j-api-2.6.2.jar, log4j-jul-2.6.2.jar and log4j2.xml to $CATALINA_HOME/bin Then changed set JAVA_OPTS=-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager set LOGGING_CONFIG=-DnoOpp set LOGGING_MANAGER=-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager set "CLASSPATH=.;%CATALINA_BASE%\bin;%CATALINA_BASE%\bin\log4j-core-2.6.2.jar;%CATALINA_BASE%\bin\log4j-api-2.6.2.jar;%CATALINA_BASE%\bin\log4j-jul-2.6.2.jar" then all woked fine THX frank -Ursprüngliche Nachricht- Von: Rainer Jung [mailto:rainer.j...@kippdata.de] Gesendet: Montag, 5. Dezember 2016 12:28 An: Tomcat Users List Betreff: Re: log4j2 configuration in Tomcat 8.5.8 Am 05.12.2016 um 08:32 schrieb frank.pien...@materna.de: > It's a little bit frustrating to configure Tomcat 8.5.8 with log4j2. > I put the following jars in $CATALINA_HOME/lib > log4j 2 core (log4j-core-2.6.2.jar) > log4j 2 api (log4j-api-2.6.2.jar) Delete the file > $CATALINA_HOME/conf/logging.properties > Put the new log4j 2 config file (log4j2.xml) in $CATALINA_HOME/lib > name="catalina" packages=""> > > > > > fileName="${catalina.base}/logs/catalina.log"> > > %d %p %c{1.} [%t] %m%n > > > > > > > > > > > > > > No errors but the created catalina.out file is empty and the console > layout doesn't change What else to check or change? > THX Frank Currently you need to put three log4j2 jar files into the CLASSPATH (not the lib directory): - core - api - jul bridge Next put your log4j2.xml in some special directory and add that directory to the CLASSPATH as well. Since in 8.5 Log4J integration is via its jul bridge it must be loadable by jul, that's why CLASSPATH and not just the lib directory. Finally add the following system property to inform jul that it should log via log4j2: -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager for instance by setting LOGGING_MANAGER to that value. To reduce confusion I suggest to also set LOGGING_CONFIG to some dummy value, e.g. -Dnop. See: http://logging.apache.org/log4j/2.x/log4j-jul/index.html There is a (minor) flaw currently in this integration: the location info (class name, method name, line number) will be wrong and always point to a fixed position in Tomcat Juli instead of the "real" class calling the log method. For more details about this problem see also: http://marc.info/?t=14774015512&r=1&w=2 Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Thread-safety of javax.servlet.Servlet#getServletConfig()
On 05/12/2016 13:40, Péter Gergely Horváth wrote: > Hi Chris, > > Thanks your four input: this question is somewhere in-between... :) > > We have *definitely* seen cases, where a piece of code like the one below > sometimes (a couple of times from tens of thousands of successfully > serviced requests) found the stored field to be null - with a > NullPointerException being thrown on the first access of the fooBarService > field. > > @WebServlet("/open") > public class FooBarServlet extends HttpServlet { > > private FooBarService fooBarService; > @Override > public void init() throws ServletException { > try { > ApplicationContext applicationContext = > (ApplicationContext) > getServletContext().getAttribute("springContext"); > fooBarService = > applicationContext.getBean("fooBarService", > FooBarService.class); > > } catch (Exception ex) { > // wrap any exceptions to ServletException so as to comply with > Servlet contract > throw new ServletException("Initialization failed with > exception", ex); > } > } > > protected void doGet(HttpServletRequest request, HttpServletResponse > response) throws ServletException, IOException { > processRequest(request, response); > } > > protected void doPost(HttpServletRequest request, HttpServletResponse > response) throws ServletException, IOException { > processRequest(request, response); > } > > private void processRequest(HttpServletRequest request, > HttpServletResponse response) throws IOException, ServletException { > > List = fooBarService.getFooBars(); /// we have seen NPEs > thrown from here > /// ... > } > > > For the first glance, it seemed to be obvious that it must have been a > threading issue, which could easily be solved by adding volatile to the > stored fooBarService field. > > However, I was more than confused seeing > that javax.servlet.GenericServlet#config uses the same approach by simply > storing the ServletConfig into a field and reading it later on without any > locking etc. > > I quickly scanned through the Servlet specs and Catalina codes, but cannot > really locate any explicit reference to thread-safety of > javax.servlet.GenericServlet#getServletConfig, that is where the question > originates. > > I would by much obliged if you had any inputs, ideas regarding this, or on > the approach one could take to confirm it on his/her own. In theory, it is a problem. In practise, I'd be surprised if anyone was ever troubled by it. Since it appears you did hit this issue, open a bug report and we'll get Tomcat's implementation fixed. Mark > > Thanks, > Peter > > > On Mon, Nov 28, 2016 at 6:45 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Péter, > > On 11/28/16 11:01 AM, Péter Gergely Horváth wrote: Thank you very much for your feedback, but I think there is a slight misunderstanding here: I know the order in which a servlet is initialized and put into service, and this question is not related to that. It's related to the _visibility_ of the field. The question is about the thread safety of the field access: if you carefully check the details of javax.servlet.GenericServlet#config and compare the implementation to the sample "NoVisibility" from the book Java Concurrency in Practice, then it is seems to follow the same pattern, which is "not thread-safe because the value field is accessed from both get and set without synchronization. Among other hazards, it is susceptible to stale values: if one thread calls set, other threads calling get may or may not see that update." [1]. Personally, I would like to understand why this implementation is not (if not) susceptible to the stale values phenomenon [2]; there might be someone, who can point me to the right direction. > > I think you are correct that there is a theoretical multi-threaded > race-condition, here. The container may initialize the servlet in one > thread and service e.g. the first request in another thread, and the > ServletContext reference might not be written to main memory and then > read-back by the request-processing thread. > > Potential fixes for this would be either to define the ServletContext > member to be volatile or to use synchronized methods.' > > Adding synchronization to the init() method would not be a problem at > all: there is very little monitor contention at that stage and the > container would only expect to call that method a single time. Adding > synchronization to the getServletContext method, though, might > represent a reduction in performance, since getServletContext gets > called many times during the lifetime of a Servlet, and from many thread > s. > > Likewise, marking the ServletContext member as "volatile" would > necessarily require a slow main-me
Re: Thread-safety of javax.servlet.Servlet#getServletConfig()
Hi Chris, Thanks your four input: this question is somewhere in-between... :) We have *definitely* seen cases, where a piece of code like the one below sometimes (a couple of times from tens of thousands of successfully serviced requests) found the stored field to be null - with a NullPointerException being thrown on the first access of the fooBarService field. @WebServlet("/open") public class FooBarServlet extends HttpServlet { private FooBarService fooBarService; @Override public void init() throws ServletException { try { ApplicationContext applicationContext = (ApplicationContext) getServletContext().getAttribute("springContext"); fooBarService = applicationContext.getBean("fooBarService", FooBarService.class); } catch (Exception ex) { // wrap any exceptions to ServletException so as to comply with Servlet contract throw new ServletException("Initialization failed with exception", ex); } } protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { processRequest(request, response); } protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { processRequest(request, response); } private void processRequest(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { List = fooBarService.getFooBars(); /// we have seen NPEs thrown from here /// ... } For the first glance, it seemed to be obvious that it must have been a threading issue, which could easily be solved by adding volatile to the stored fooBarService field. However, I was more than confused seeing that javax.servlet.GenericServlet#config uses the same approach by simply storing the ServletConfig into a field and reading it later on without any locking etc. I quickly scanned through the Servlet specs and Catalina codes, but cannot really locate any explicit reference to thread-safety of javax.servlet.GenericServlet#getServletConfig, that is where the question originates. I would by much obliged if you had any inputs, ideas regarding this, or on the approach one could take to confirm it on his/her own. Thanks, Peter On Mon, Nov 28, 2016 at 6:45 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Péter, > > On 11/28/16 11:01 AM, Péter Gergely Horváth wrote: > > Thank you very much for your feedback, but I think there is a > > slight misunderstanding here: I know the order in which a servlet > > is initialized and put into service, and this question is not > > related to that. It's related to the _visibility_ of the field. > > > > The question is about the thread safety of the field access: if > > you carefully check the details of > > javax.servlet.GenericServlet#config and compare the implementation > > to the sample "NoVisibility" from the book Java Concurrency in > > Practice, then it is seems to follow the same pattern, which is > > "not thread-safe because the value field is accessed from both get > > and set without synchronization. Among other hazards, it is > > susceptible to stale values: if one thread calls set, other threads > > calling get may or may not see that update." [1]. > > > > Personally, I would like to understand why this implementation is > > not (if not) susceptible to the stale values phenomenon [2]; there > > might be someone, who can point me to the right direction. > > I think you are correct that there is a theoretical multi-threaded > race-condition, here. The container may initialize the servlet in one > thread and service e.g. the first request in another thread, and the > ServletContext reference might not be written to main memory and then > read-back by the request-processing thread. > > Potential fixes for this would be either to define the ServletContext > member to be volatile or to use synchronized methods.' > > Adding synchronization to the init() method would not be a problem at > all: there is very little monitor contention at that stage and the > container would only expect to call that method a single time. Adding > synchronization to the getServletContext method, though, might > represent a reduction in performance, since getServletContext gets > called many times during the lifetime of a Servlet, and from many thread > s. > > Likewise, marking the ServletContext member as "volatile" would > necessarily require a slow main-memory read every time > getServletContext is called. > > I suspect simple analysis above is the reason for no multithreaded > protection being placed on the ServletContext member in question. > > Péter, is this an academic discussion, or have you in fact seen a case > where a servlet has been initialized and yet the first thread to > process a request receives a null value wh
Re: log4j2 configuration in Tomcat 8.5.8
Am 05.12.2016 um 08:32 schrieb frank.pien...@materna.de: It's a little bit frustrating to configure Tomcat 8.5.8 with log4j2. I put the following jars in $CATALINA_HOME/lib log4j 2 core (log4j-core-2.6.2.jar) log4j 2 api (log4j-api-2.6.2.jar) Delete the file $CATALINA_HOME/conf/logging.properties Put the new log4j 2 config file (log4j2.xml) in $CATALINA_HOME/lib %d %p %c{1.} [%t] %m%n No errors but the created catalina.out file is empty and the console layout doesn't change What else to check or change? THX Frank Currently you need to put three log4j2 jar files into the CLASSPATH (not the lib directory): - core - api - jul bridge Next put your log4j2.xml in some special directory and add that directory to the CLASSPATH as well. Since in 8.5 Log4J integration is via its jul bridge it must be loadable by jul, that's why CLASSPATH and not just the lib directory. Finally add the following system property to inform jul that it should log via log4j2: -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager for instance by setting LOGGING_MANAGER to that value. To reduce confusion I suggest to also set LOGGING_CONFIG to some dummy value, e.g. -Dnop. See: http://logging.apache.org/log4j/2.x/log4j-jul/index.html There is a (minor) flaw currently in this integration: the location info (class name, method name, line number) will be wrong and always point to a fixed position in Tomcat Juli instead of the "real" class calling the log method. For more details about this problem see also: http://marc.info/?t=14774015512&r=1&w=2 Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Two Way SSL - SSL Offloading at load balancer
Hi all, Probably the FW can be configured to not terminate the SSL connection. It should act as a pass-through. But since few months we noticed that Tomcat is not requesting the client certificate anymore (Tomcat to Tomcat, the browsers always receive a certificate request). It complete the handshake so the SSL communication is established but no certificate is sent. If I got this right is because something has been changed in a later revision in Java 8. To force Tomcat to request the client certificate we had to set clientAuth to true. Just my 2 cents. Kind Regards, Diego Macca Senior IT Specialist DG-IS/EDA - Executional Domain Applications EUROPEAN CENTRAL BANK Tel.: +49 (69) 1344 6991 E-mail: diego.ma...@ecb.europa.eu www.ecb.europa.eu www.youtube.com/ecbeuro https://twitter.com/ecb -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: 02 December 2016 17:09 To: Tomcat Users List Subject: Re: Two Way SSL - SSL Offloading at load balancer -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bipin, On 12/2/16 7:27 AM, Bipin Jethwani wrote: > We use Spring security and want to use Two Way SSL for a few Jersey > based REST APIs exposed for mobile devices. SSL is offloaded at > load-balancer or apache level. > > Can we still get access to client certificate at web app level? That depends. How are you connecting your load-balancer to Tomcat. Can you configure the load-balancer to forward the TLS details to Tomcat? With httpd, both mod_jk and mod_proxy_ajp can do it natively. Using mod_proxy_httpd, you just have to make sure that the certificates are forwarded as HTTP request headers, and you'll need to configure the RemoteIPValve to unpack that information and put it into the HttpServletRequest object in a place your application might expect it to be. > On second thought we can live without having access to client cert but > can we have load-balancer or apache configured to request for client > cert only for a specific urls? No. Only the component terminating TLS can request a certificate from the client. If there is a way for you to signal to the load-balancer that you want to request a certificate, then the load-balancer can request a TLS renegotiation and ask for a client certificate at that point. > Is there a standard for this? None that I know of. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYQZySAAoJEBzwKT+lPKRYD3kP/00panFQA1oqLeU6NvAySvwc gHyxLLt4PKSRJrlrczk/ftw8czjepDQx3Z4Rk4bQ3x4EwFNcqv+DnvfBuRv0f3W8 15fzIQhRcULvkdhJ+AHWW73y3wsoRl0U1f6nAAma6nevZgbmXy3efUIWeIFZy7RY o8qLBfTy5krcPft9GMMEjGVtkWOB54NFoRe3Sp8iE1CR3jw8oGyzE2i3WdJKhsxE iFoJcnNJH65sBKwL2LtpahgaZ6YeRGa7SLcYgTkcldyfqEEd1zZYlBQTZFQh6Zy0 BEUTWz99r5klMaU0Zn7QiYfFrWkA0pF4agdFnsWElj2ZsJ2YAC+ckAsZ7Rj2oHwD s4ehb6zCGeTE/bToD4nlb1iizZuWTIlFCzhZ3d/iYNHVCnICOdt0IyPAV/cVl9iL r9htFbB6hzd05ALP5MfLzqluhP5sGhuKhBK5glda3prLP2L7b14IxbfuOGTYbgPV q7fTfLfim7veQYpZWoRIdUjqkQM9BN43AkX3HyGF15SirL9U0NEXQkiipHR0Fi3E FR3JmDcsphMV+bvHnzHeVbMEzNrai1GZhZ6Y+6IW2iRGwgWcfO4nCU10ZPGDh50H 2sW0R27nZviNHocLGgSJsmGFO98rrUHlHYXpPCn+NTFAF+zwE0S5d6qf5RFKtGWr 8xiy+1gtF7s/tSQhVlap =83a5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Any e-mail message from the European Central Bank (ECB) is sent in good faith, but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system. The ECB processes personal data in line with Regulation (EC) No 45/2001 and Decision ECB/2007/1. For any further information you can consult the Data Protection Disclaimer on the ECB webpage. In case of queries, please contact the ECB Data Protection Officer (d...@ecb.europa.eu). You may also contact the European Data Protection Supervisor.