Re: encrypting passwords in tomcat-users.xml

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Guy,

On 11/20/17 1:23 PM, Guy Mac wrote:
> I'm failing to figure out how to encrypt passwords for (slightly) 
> different versions of Tomcat 8.0.x on different platforms.

Some background: older versions of Tomcat only supported single-round
hashing such as MD5, SHA-1, SHA-256, etc. and the newer versions
support many more options including pluggable modules to do whatever
you want. Most people will be able to use the baked-in modules to get
what they want, but you can build your own if you need something special
.

> With Tomcat 8.0.37 on MacOS, I run digest.sh with a password,
> placing the output in tomcat-users

Specifically, how do you run this?

> , and update the Realm for the Catalina engine to:  className="org.apache.catalina.realm.LockOutRealm">  className="org.apache.catalina.realm.UserDatabaseRealm" 
> resourceName="UserDatabase">  className="org.apache.catalina.realm.MessageDigestCredentialHandler"
>
> 
algorithm="SHA-512"/>
>  
> 
> and that all works just fine.

Good.

> But when I try to repeat the steps for Tomcat 8.0.14-1 on Linux 
> (Debian), it does not work. How do I encrypt passwords for this
> version of Tomcat?

The process should should be the same, and the hash should be the same
no matter what what version of Tomcat you use to produce it, and no
matter what platform you use.

- From a Tomcat 7.0.x install:

$ $CATALINA_HOME/bin/digest.sh -a SHA-512 's3cret'
s3cret:1ec1c26b50d5d3c58d9583181af8076655fe00756bf7285940ba3670f99fcba0

[Note that if you put that on the command-line it will be in your
shell's history for anyone to see. Try using a leading space character
to keep some shells from keeping the command in the history.]

- From a Tomcat 8.0.x install:
$ $CATALINA_HOME/bin/digest.sh -a SHA-256 s3cret
s3cret:46e78df675f5842ebca3f67679a3ce14fd3ddb08727feacba84935f58914d49b$
1$4e72031fe6f751d3b2390cd494971b8bf27cccf41f5ea8d7f56272f15b091207

Wait, what?! It turns out that Tomcat 8.0.x uses a salted, iterated
hash by default and so you get (a) more protection and (b) more stuff
coming out.

If you want to get the same thing you got from Tomcat 7.0.x, you'll
need some additional command-line arguments:

$ $CATALINA_HOME/bin/digest.sh -a SHA-256 -i 1 -s 0 s3cret
s3cret:1ec1c26b50d5d3c58d9583181af8076655fe00756bf7285940ba3670f99fcba0

This is true of Tomcat 8.5.x and Tomcat 9.0.x as well.

Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloTTrIdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFifYQ/+L8MPYoTQDLmFOnJF
uQHnuB8HPJZjde9jCCx4cGsnPFiMUk9aiefqNwAskyl4AhJt/AStSW2kEHUf483O
UxBsfAcgzuwxeUFiJGzIRKgzX7ziAgBrKisGM5hBDmu3NYwtIdkKWpwrPLhm9fsy
YPzj9Xo/iTDXvEA2fjlNvHuGMfNNruYL/dxfLmCeWfQrQ4eZIU3j/nAouvhXP3YY
+x076mU700+A7MgLt4xJXVthyvCZbxWF7LspSA5J9L3/05KUWOoR25xjJ84dX3g2
laR9q8GE8Y4+LvU5zJpgZ2sHsFaVpqksoU2lD8p4tQsOix3XILt7+/oBlipil4mG
k9FI17e3AQH9LqAajzPwU6QFKxIRsAoS4BS3fWc80f4O7np9ouqZ3Dwa62ctLG+Z
PBx4ra1BNoBPkmetGzHE1bFzn5hQf+0Lrq0XXt/cp5Uyqk/0123YtEvpc6J0T+YC
3gNAJyYHOvf6TBASFN8ve5fBesL1g7X5Qtk4IOu/C4vWEK+Tu02b3ewNPX/rMCGX
Pf9JiBxqA4qGhN0pNyygxM7rlAoo5bdcPwxd+pFDmnYtPbw6QGpRrnyUVuuqOhVS
WxB5FwJhXkjv4cMKkw0bgEcBvdzJOZumfMQh0SRsHJz0JhjeYuJJ8qpXZ13Ab7lt
iRkZejsgB1R37ufhutqOoOpbLN4=
=T2tz
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

encrypting passwords in tomcat-users.xml

[Guy Mac]

I'm failing to figure out how to encrypt passwords for (slightly) 
different versions of Tomcat 8.0.x on different platforms.


With Tomcat 8.0.37 on MacOS, I run digest.sh with a password, placing 
the output in tomcat-users, and update the Realm for the Catalina engine to:

  
    resourceName="UserDatabase">
  className="org.apache.catalina.realm.MessageDigestCredentialHandler" 
algorithm="SHA-512"/>

    
  

and that all works just fine.

But when I try to repeat the steps for Tomcat 8.0.14-1 on Linux 
(Debian), it does not work. How do I encrypt passwords for this version 
of Tomcat?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Skip resource path in TLD scanner?

[Matt Cosentino]

Thanks, but I'm talking about resource paths and not jar files.

- Matt

From: Ray Holme [mailto:rayho...@yahoo.com.INVALID]
Sent: Friday, November 17, 2017 1:39 PM
To: Tomcat Users List 
Subject: Re: Skip resource path in TLD scanner?

I use JSP and there are taglibs used.
But you can cut the scan time way down by not scanning any libraries that don't 
have TLDs
 (nested files with name => .tld)
You can find this by using "jar t" or "unzip -l" on each library (thanks Chris).

If you are a Unix (Linux or MAC) user you may cheat a little by using the 
script attached.
You may put any all .jar files in .../apache/lib or 
.../apache/webapps/*/WEB-INF/lib into the
  .../apache/conf/catalina.properties file if they do not have taglibs.
So 90% of what I need does not have taglibs (just jstl-impl-...jar DOES and 
must be left out of the DO NO SCAN line.
This took my startup time from a couple minutes to under a second.

Best of luck.

On Friday, November 17, 2017 1:26 PM, Christopher Schultz 
> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Matt,

On 11/16/17 12:11 PM, Matt Cosentino wrote:
> This keeps getting worse, my site was down for over a minute while
> the TLD scanner ran. There must be something I can do.
If you need taglibs, you'll need to do TLS scanning. There really is
no way to avoid that that I know of. One of many reasons I don't like
JSP as a technology.

If you are having a problem with downtime, you have other options that
might help in other areas. For example, you could set up a second
server and load-balance between the two of them. This protects you
from a number of downtime-causing issues such as power failures, JVM
crashes, and -- as in your example here -- planned maintenance.

Running a single instance of your application in a production
environment where uptime matters is really not an appropriate
solution. If you had two servers, your application's restart time
would not have been an issue.

- -chris

> -Original Message- From: Mark Thomas
> [mailto:ma...@apache.org] Sent: Saturday, April 29, 
> 2017 5:02 AM
> To: Tomcat Users List 
> > Subject: Re: Skip
> resource path in TLD scanner?
>
> On 28/04/17 17:00, Matt Cosentino wrote:
>> Yes, it's other folders within WEB-INF. I turned on the
>> TldScanner logging and it is definitely what is causing the
>> delay. My situation probably isn't very typical. The delay varies
>> in my various web applications, the worst being about 20 seconds.
>> It all adds up though, and every second counts when our sites are
>> down.
>
> There is a solution available but it is intended more for the
> embedded use case rather than a standard Tomcat install. Using it
> in a standard install would require (effectively) patching Tomcat.
>
> The general idea would be to use the TldPreScanned class. That does
> require all the TLDs to be listed in advance. On the plus side, no
> scanning delay. On the down side, adding TLDs requires code
> changes. Doing this with a standard Tomcat install requires changes
> to the JasperInitializer (hence the patch). I don't think there is
> a pure config way around that but I'll look into it.
>
> A better solution would probably be to make it easier to plugin in
> a custom TLDScanner - i.e. purely with config. If you'd like us to
> explore this option we should re-open 61052 and adjust accordingly.
> I don't think there is enough demand for filtering resource paths
> to make that worth implementing.
>
> One final thought. Are you running the web application from a WAR
> or an expanded directory? (The latter would be faster).
>
> Mark
>
>
>
>>
>> - Matt
>>
>>
>> -Original Message- From: Mark Thomas
>> [mailto:ma...@apache.org] Sent: Friday, April 28, 
>> 2017 7:28 AM
>> To: Tomcat Users List 
>> > Subject: Re: Skip
>> resource path in TLD scanner?
>>
>> On 27/04/17 23:39, Matt Cosentino wrote:
>>> https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html
>>>
>>>
>>>
There is one for skipping jar files:
>>>
>>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip
>>
>> 
>>
>>> It skips /WEB-INF/classes/ and /WEB-INF/lib/, but it does not
>>> check any property to skip user defined paths.
>>
>> Is it other paths within WEB-INF you need to skip?
>>
>> When I read "skipping resource paths" I was thinking of skipping
>> the various places where Tomcat treat directories as JARs that
>> then get scanned for TLDs (which can be configured via the
>> JarScanner). But it sounds like skipping those won't help you.
>>
>> How sure are you that it is checking the directories below
>> WEB-INF that is the cause of the delay? That isn't a typical
>> source of start-up delay although it is certainly possible.
>>
>> Finally, what sort of delay are we talking out here? 

RE: Skip resource path in TLD scanner?

[Matt Cosentino]

While that is good advice, it's not necessarily an appropriate solution for 
this. It's not that I don't want any TLD scanning, it's that it is scanning 
folders that I know don't have TLDs and there is no reason to scan them. The 
scanner already decides to skip the classes and lib paths, so it could 
definitely skip a user defined list of paths. I guess for now I could see if I 
can move the files in these paths out of WEB-INF to keep them from being 
scanned.

- Matt

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Friday, November 17, 2017 12:26 PM
To: users@tomcat.apache.org
Subject: Re: Skip resource path in TLD scanner?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Matt,

On 11/16/17 12:11 PM, Matt Cosentino wrote:
> This keeps getting worse, my site was down for over a minute while the 
> TLD scanner ran. There must be something I can do.
If you need taglibs, you'll need to do TLS scanning. There really is no way to 
avoid that that I know of. One of many reasons I don't like JSP as a technology.

If you are having a problem with downtime, you have other options that might 
help in other areas. For example, you could set up a second server and 
load-balance between the two of them. This protects you from a number of 
downtime-causing issues such as power failures, JVM crashes, and -- as in your 
example here -- planned maintenance.

Running a single instance of your application in a production environment where 
uptime matters is really not an appropriate solution. If you had two servers, 
your application's restart time would not have been an issue.

- -chris

> -Original Message- From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Saturday, April 29, 2017 5:02 AM
> To: Tomcat Users List  Subject: Re: Skip 
> resource path in TLD scanner?
> 
> On 28/04/17 17:00, Matt Cosentino wrote:
>> Yes, it's other folders within WEB-INF. I turned on the TldScanner 
>> logging and it is definitely what is causing the delay. My situation 
>> probably isn't very typical. The delay varies in my various web 
>> applications, the worst being about 20 seconds.
>> It all adds up though, and every second counts when our sites are 
>> down.
> 
> There is a solution available but it is intended more for the embedded 
> use case rather than a standard Tomcat install. Using it in a standard 
> install would require (effectively) patching Tomcat.
> 
> The general idea would be to use the TldPreScanned class. That does 
> require all the TLDs to be listed in advance. On the plus side, no 
> scanning delay. On the down side, adding TLDs requires code changes. 
> Doing this with a standard Tomcat install requires changes to the 
> JasperInitializer (hence the patch). I don't think there is a pure 
> config way around that but I'll look into it.
> 
> A better solution would probably be to make it easier to plugin in a 
> custom TLDScanner - i.e. purely with config. If you'd like us to 
> explore this option we should re-open 61052 and adjust accordingly.
> I don't think there is enough demand for filtering resource paths to 
> make that worth implementing.
> 
> One final thought. Are you running the web application from a WAR or 
> an expanded directory? (The latter would be faster).
> 
> Mark
> 
> 
> 
>> 
>> - Matt
>> 
>> 
>> -Original Message- From: Mark Thomas 
>> [mailto:ma...@apache.org] Sent: Friday, April 28, 2017 7:28 AM
>> To: Tomcat Users List  Subject: Re: Skip 
>> resource path in TLD scanner?
>> 
>> On 27/04/17 23:39, Matt Cosentino wrote:
>>> https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html
>>>
>>>
>>> 
There is one for skipping jar files:
>>> 
>>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip
>> 
>> 
>> 
>>> It skips /WEB-INF/classes/ and /WEB-INF/lib/, but it does not check 
>>> any property to skip user defined paths.
>> 
>> Is it other paths within WEB-INF you need to skip?
>> 
>> When I read "skipping resource paths" I was thinking of skipping the 
>> various places where Tomcat treat directories as JARs that then get 
>> scanned for TLDs (which can be configured via the JarScanner). But it 
>> sounds like skipping those won't help you.
>> 
>> How sure are you that it is checking the directories below WEB-INF 
>> that is the cause of the delay? That isn't a typical source of 
>> start-up delay although it is certainly possible.
>> 
>> Finally, what sort of delay are we talking out here? Seconds? 
>> Minutes?
>> 
>> Mark
>> 
>> 
>>> -Original Message- From: Mark Thomas 
>>> [mailto:ma...@apache.org] Sent: Thursday, April 27, 2017 5:05 PM To: 
>>> Tomcat Users List  Subject: Re:
>>> Skip resource path in TLD scanner?
>>> 
>>> On 27/04/17 21:17, Matt Cosentino wrote:
 I need to skip some of the resource paths within WEB-INF. I know 
 there's a property for skipping jar files, but I couldn't find one 
 for resource paths. I 

RE: Multiple errors

[Karen Goh]

Hi all,

I managed to get the errors to go away by installing a higher version Tomcat 
and also update my windows environment variable to JDK 8.
Thanks for all the replies.



On Mon, 11/20/17, Nicolas Therrien  wrote:

 Subject: RE: Multiple errors
 To: "users@tomcat.apache.org" 
 Date: Monday, November 20, 2017, 8:37 PM
 
 If you have autodeploy set to ON,
 make sure you clean your webapps from any leftover war
 files.   I would delete the folder contents entirely and
 redeploy.
 
 
 
 
 On 19.11.2017 07:32, Karen Goh
 wrote:
 > Hi,
 >
 > I am writing to this group as I could not
 get an answer from anywhere.
 >
 > Basically, I do not know what happened cos
 my Tomcat was running fine and then I got a bunch of
 error.
 >
 > I did a mvn
 clean, delete all my dependencies in my .m2 repositotries
 and rebuilt, re-installed Tomcat many times but to no
 avail.
 >
 > My tomcat
 is in my built path in my Eclipse NEON.
 >
 > So, I really hope
 someone can let me know what went wrong.
 
 I'm not the expert, but it looks as if one
 of the .jar files composing tomcat may be corrupt.
 I am basing this on the following lines below
 :
 
 [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Hi5S]]
 ...
  > Caused by:
 java.lang.IllegalArgumentException:
 java.util.zip.ZipException: invalid LOC header (bad
 signature)
 
 (a .jar file is
 a zip file containing java programs and libraries)
 
 "/Hi5S" does not
 look like it is any part of a standard tomcat, so maybe it
 is in your application rather than tomcat itself.
 
 >
 >
 Here's the error message :
 >
 > Nov 19, 2017 2:30:29 PM
 org.apache.catalina.core.StandardService 
 > startInternal
 > INFO:
 Starting service [Catalina]
 > Nov 19,
 2017 2:30:29 PM org.apache.catalina.core.StandardEngine 
 > startInternal
 > INFO:
 Starting Servlet Engine: Apache Tomcat/8.5.23 Nov 19, 2017
 
 > 2:30:30 PM
 org.apache.catalina.core.ContainerBase startInternal
 > SEVERE: A child container failed during
 start
 >
 java.util.concurrent.ExecutionException:
 org.apache.catalina.LifecycleException: Failed to start
 component
 [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Hi5S]]
 >     at
 java.util.concurrent.FutureTask.report(Unknown Source)
 >     at
 java.util.concurrent.FutureTask.get(Unknown Source)
 >     at
 org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:939)
 >     at
 org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:872)
 >     at
 org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 >     at
 org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
 >     at
 org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
 >     at
 java.util.concurrent.FutureTask.run(Unknown Source)
 >     at
 java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
 Source)
 >     at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
 Source)
 >     at
 java.lang.Thread.run(Unknown Source) Caused by: 
 > org.apache.catalina.LifecycleException:
 Failed to start component
 [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Hi5S]]
 >     at
 org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
 >     ... 6 more
 >
 Caused by: org.apache.catalina.LifecycleException: Failed to
 start component [org.apache.catalina.webresources.StandardRoot@59d0966f]
 >     at
 org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
 >     at
 
org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4860)
 >     at
 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4995)
 >     at
 org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 >     ... 6 more
 >
 Caused by: org.apache.catalina.LifecycleException: Failed to
 initialize component [org.apache.catalina.webresources.JarResourceSet@38099cbe]
 >     at
 org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:113)
 >     at
 org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:140)
 >     at
 
org.apache.catalina.webresources.StandardRoot.startInternal(StandardRoot.java:724)
 >     at
 org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 >     ... 9 more
 >
 Caused by: java.lang.IllegalArgumentException:
 java.util.zip.ZipException: invalid LOC header (bad
 signature)
 >     at
 
org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.initInternal(AbstractSingleArchiveResourceSet.java:113)
 >     at
 org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
 >     ... 12 more
 >
 Caused by: java.util.zip.ZipException: invalid LOC header
 (bad signature)
 >     at
 java.util.zip.ZipFile.read(Native Method)
 >     at
 java.util.zip.ZipFile.access$1400(Unknown Source)
 >     at
 java.util.zip.ZipFile$ZipFileInputStream.read(Unknown
 Source)
 >     at
 

Re: Supported callbacks in Tomcat JASPIC implementation

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark and Lazar,

On 11/18/17 10:05 AM, Mark Thomas wrote:
> On 18/11/17 14:20, Lazar Kirchev wrote:
>> Hello Marc,
>> 
>> Do you think it makes sense to make the CallbackHandler
>> implementation class configurable, e.g. to be able to specify its
>> name via a property?
> 
> As a property on the authenticator? I don't see why not.

+1

Also, we should arrange to allow for multiple callback handlers to be
supported.

>> In this way if support for additional callbacks is necessary
>> someone could plug a custom CallbackHandler providing such a
>> support. The current CallbackHandlerImpl would remain the default
>> one.
>> 
>> Regarding jaspic, as I played around a little bit with it I found
>> the following small problems (all bugzilla issues contain also a
>> pull request with a patch proposal):

Fantastic! Thanks for your contributions!

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloS5YkACgkQHPApP6U8
pFgznxAAl7+ujEV0K520FcIckJFnz8qLnoTRBz5qlCVFJOBAUVBbNL9zJTUs/n6K
/EOVEWmvB26reIvyxprw9UXbhtanukpmYrQ6DWpPsH03z6WIQJhmZ4BXw+XJklJS
YE2A3GldT0+wgArSM00bHjDR6gZaHPuTutO9Gpk0su9uw1Erd41dNj53tYqQ9254
pNqhS+tsI8ayQ7zMrNHIzR/C/beS3IOURyyAxHL7wGMGBq83O6+l8u0tTzR5+j0t
vFLHa1Q6uVAkofJmOzXehBbX3k7wU6HQdSIXZWcEG8Qhn6i8sjfXJw8cRf7YOIYY
Ou5smdWPWEcnQlYDIUwyMx6+/yXhgUgV6chai+tFsNBLlMjNBCjhVmqXB1Jc9kPK
fRo6KmcPTaCBip5qk4QdtenY7/5Swi+y9SFKu4AXTxsWx2MvVO/Xupp3RsYocybT
8V8UNmTGbxgRUMyFLjCFN5rPwt6OvgCPle99rMJXtWObGZFdiVL7RhLhoh9mXl8D
tUyATSWG+etqn6xn5VlnI9si10hvPcgkWfPn+nEIEWQAbjoi5UP0f2BaFdk3mX8+
t+m+AKup3eiHlSxI/YCwotSQ6+3W7AuSPsZ+O31AFAid54zkw7ZUGniYC4w5wwtq
oxIrCOJAmWGbIWotCNlqTm8liV9FhtpzYkNvG/eFIxv9rtsuYm4=
=McTq
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Skip resource path in TLD scanner?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alex,

On 11/18/17 8:30 AM, Alex O'Ree wrote:
> I'm having similar issues after updating from tomcat7 to tomcat8.5.
> The build script for my app adds some sql drivers to tomcat's lib
> folder, specifically the derby driver. On bootup tomcat logs a ton
> of error messages saying that it couldn't find (what looks to be)
> internationalized resource files for derby, which aren't present.

Please start another thread and we can probably help you with that. It
likely has nothing to do with Tomcat, though.

- -chris

> On Fri, Nov 17, 2017 at 2:39 PM, Ray Holme
>  wrote:
> 
>> I use JSP and there are taglibs used. But you can cut the scan
>> time way down by not scanning any libraries that don't have TLDs 
>> (nested files with name => .tld) You can find this by using "jar
>> t" or "unzip -l" on each library (thanks Chris).
>> 
>> If you are a Unix (Linux or MAC) user you may cheat a little by
>> using the script attached. You may put any all .jar files in
>> .../apache/lib or .../apache/webapps/*/WEB-INF/lib into the 
>> .../apache/conf/catalina.properties file if they do not have
>> taglibs. So 90% of what I need does not have taglibs (just
>> jstl-impl-...jar DOES and must be left out of the DO NO SCAN
>> line. This took my startup time from a couple minutes to under a
>> second.
>> 
>> Best of luck.
>> 
>> 
>> On Friday, November 17, 2017 1:26 PM, Christopher Schultz < 
>> ch...@christopherschultz.net> wrote:
>> 
>> 
> Matt,
> 
> On 11/16/17 12:11 PM, Matt Cosentino wrote:
 This keeps getting worse, my site was down for over a minute
 while the TLD scanner ran. There must be something I can do.
> If you need taglibs, you'll need to do TLS scanning. There really
> is no way to avoid that that I know of. One of many reasons I don't
> like JSP as a technology.
> 
> If you are having a problem with downtime, you have other options
> that might help in other areas. For example, you could set up a
> second server and load-balance between the two of them. This
> protects you from a number of downtime-causing issues such as power
> failures, JVM crashes, and -- as in your example here -- planned
> maintenance.
> 
> Running a single instance of your application in a production 
> environment where uptime matters is really not an appropriate 
> solution. If you had two servers, your application's restart time 
> would not have been an issue.
> 
> -chris
> 
 -Original Message- From: Mark Thomas 
 [mailto:ma...@apache.org] Sent: Saturday, April 29, 2017 5:02
 AM To: Tomcat Users List  Subject:
 Re: Skip resource path in TLD scanner?
 
 On 28/04/17 17:00, Matt Cosentino wrote:
> Yes, it's other folders within WEB-INF. I turned on the 
> TldScanner logging and it is definitely what is causing
> the delay. My situation probably isn't very typical. The
> delay varies in my various web applications, the worst
> being about 20 seconds. It all adds up though, and every
> second counts when our sites are down.
 
 There is a solution available but it is intended more for
 the embedded use case rather than a standard Tomcat install.
 Using it in a standard install would require (effectively)
 patching Tomcat.
 
 The general idea would be to use the TldPreScanned class.
 That does require all the TLDs to be listed in advance. On
 the plus side, no scanning delay. On the down side, adding
 TLDs requires code changes. Doing this with a standard Tomcat
 install requires changes to the JasperInitializer (hence the
 patch). I don't think there is a pure config way around that
 but I'll look into it.
 
 A better solution would probably be to make it easier to
 plugin in a custom TLDScanner - i.e. purely with config. If
 you'd like us to explore this option we should re-open 61052
 and adjust accordingly. I don't think there is enough demand
 for filtering resource paths to make that worth
 implementing.
 
 One final thought. Are you running the web application from a
 WAR or an expanded directory? (The latter would be faster).
 
 Mark
 
 
 
> 
> - Matt
> 
> 
> -Original Message- From: Mark Thomas 
> [mailto:ma...@apache.org] Sent: Friday, April 28, 2017 7:28
> AM To: Tomcat Users List  Subject:
> Re: Skip resource path in TLD scanner?
> 
> On 27/04/17 23:39, Matt Cosentino wrote:
>> https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html
>>
>>
>>
>
>> 
There is one for skipping jar files:
>> 
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip
> 
> 
> 
>> It skips /WEB-INF/classes/ and /WEB-INF/lib/, but it does
>> not check any property to skip user defined paths.
> 
> Is it other paths within WEB-INF you need to skip?
> 

RE: Multiple errors

[Nicolas Therrien]

If you have autodeploy set to ON, make sure you clean your webapps from any 
leftover war files.   I would delete the folder contents entirely and redeploy.




On 19.11.2017 07:32, Karen Goh wrote:
> Hi,
>
> I am writing to this group as I could not get an answer from anywhere.
>
> Basically, I do not know what happened cos my Tomcat was running fine and 
> then I got a bunch of error.
>
> I did a mvn clean, delete all my dependencies in my .m2 repositotries and 
> rebuilt, re-installed Tomcat many times but to no avail.
>
> My tomcat is in my built path in my Eclipse NEON.
>
> So, I really hope someone can let me know what went wrong.

I'm not the expert, but it looks as if one of the .jar files composing tomcat 
may be corrupt.
I am basing this on the following lines below :

[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Hi5S]]
...
 > Caused by: java.lang.IllegalArgumentException: java.util.zip.ZipException: 
 > invalid LOC header (bad signature)

(a .jar file is a zip file containing java programs and libraries)

"/Hi5S" does not look like it is any part of a standard tomcat, so maybe it is 
in your application rather than tomcat itself.

>
> Here's the error message :
>
> Nov 19, 2017 2:30:29 PM org.apache.catalina.core.StandardService 
> startInternal
> INFO: Starting service [Catalina]
> Nov 19, 2017 2:30:29 PM org.apache.catalina.core.StandardEngine 
> startInternal
> INFO: Starting Servlet Engine: Apache Tomcat/8.5.23 Nov 19, 2017 
> 2:30:30 PM org.apache.catalina.core.ContainerBase startInternal
> SEVERE: A child container failed during start
> java.util.concurrent.ExecutionException: 
> org.apache.catalina.LifecycleException: Failed to start component 
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Hi5S]]
>   at java.util.concurrent.FutureTask.report(Unknown Source)
>   at java.util.concurrent.FutureTask.get(Unknown Source)
>   at 
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:939)
>   at 
> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:872)
>   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>   at 
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
>   at 
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
>   at java.util.concurrent.FutureTask.run(Unknown Source)
>   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>   at java.lang.Thread.run(Unknown Source) Caused by: 
> org.apache.catalina.LifecycleException: Failed to start component 
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Hi5S]]
>   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
>   ... 6 more
> Caused by: org.apache.catalina.LifecycleException: Failed to start component 
> [org.apache.catalina.webresources.StandardRoot@59d0966f]
>   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
>   at 
> org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4860)
>   at 
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4995)
>   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>   ... 6 more
> Caused by: org.apache.catalina.LifecycleException: Failed to initialize 
> component [org.apache.catalina.webresources.JarResourceSet@38099cbe]
>   at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:113)
>   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:140)
>   at 
> org.apache.catalina.webresources.StandardRoot.startInternal(StandardRoot.java:724)
>   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>   ... 9 more
> Caused by: java.lang.IllegalArgumentException: java.util.zip.ZipException: 
> invalid LOC header (bad signature)
>   at 
> org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.initInternal(AbstractSingleArchiveResourceSet.java:113)
>   at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>   ... 12 more
> Caused by: java.util.zip.ZipException: invalid LOC header (bad signature)
>   at java.util.zip.ZipFile.read(Native Method)
>   at java.util.zip.ZipFile.access$1400(Unknown Source)
>   at java.util.zip.ZipFile$ZipFileInputStream.read(Unknown Source)
>   at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(Unknown Source)
>   at java.util.zip.InflaterInputStream.read(Unknown Source)
>   at sun.misc.IOUtils.readFully(Unknown Source)
>   at java.util.jar.JarFile.getBytes(Unknown Source)
>   at java.util.jar.JarFile.getManifestFromReference(Unknown Source)
>   at java.util.jar.JarFile.getManifest(Unknown Source)
>   at 
> 

Re: Supported callbacks in Tomcat JASPIC implementation

[Lazar Kirchev]

> Do you think it makes sense to make the CallbackHandler implementation
> > class configurable, e.g. to be able to specify its name via a property?
>
> As a property on the authenticator? I don't see why not.


Yes, something like that: https://github.com/apache/tomcat/pull/93



> > In
> > this way if support for additional callbacks is necessary someone could
> > plug a custom CallbackHandler providing such a support. The current
> > CallbackHandlerImpl would remain the default one.
> >
> > Regarding jaspic, as I played around a little bit with it I found the
> > following small problems (all bugzilla issues contain also a pull request
> > with a patch proposal):
>
> Thanks. Hopefully they'll get looked at before the next set of releases.

Thanks. I don't think they are very urgent so it will be OK even if they go
in some later release.

Regards,
Lazar

Re: Multiple errors

[tomcat]

On 19.11.2017 07:32, Karen Goh wrote:

Hi,

I am writing to this group as I could not get an answer from anywhere.

Basically, I do not know what happened cos my Tomcat was running fine and then 
I got a bunch of error.

I did a mvn clean, delete all my dependencies in my .m2 repositotries and 
rebuilt, re-installed Tomcat many times but to no avail.

My tomcat is in my built path in my Eclipse NEON.

So, I really hope someone can let me know what went wrong.


I'm not the expert, but it looks as if one of the .jar files composing tomcat 
may be corrupt.
I am basing this on the following lines below :

[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Hi5S]]
...
> Caused by: java.lang.IllegalArgumentException: java.util.zip.ZipException: invalid LOC 
header (bad signature)


(a .jar file is a zip file containing java programs and libraries)

"/Hi5S" does not look like it is any part of a standard tomcat, so maybe it is in your 
application rather than tomcat itself.




Here's the error message :

Nov 19, 2017 2:30:29 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service [Catalina]
Nov 19, 2017 2:30:29 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/8.5.23
Nov 19, 2017 2:30:30 PM org.apache.catalina.core.ContainerBase startInternal
SEVERE: A child container failed during start
java.util.concurrent.ExecutionException: 
org.apache.catalina.LifecycleException: Failed to start component 
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Hi5S]]
at java.util.concurrent.FutureTask.report(Unknown Source)
at java.util.concurrent.FutureTask.get(Unknown Source)
at 
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:939)
at 
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:872)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.catalina.LifecycleException: Failed to start component 
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Hi5S]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
... 6 more
Caused by: org.apache.catalina.LifecycleException: Failed to start component 
[org.apache.catalina.webresources.StandardRoot@59d0966f]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
at 
org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4860)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4995)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 6 more
Caused by: org.apache.catalina.LifecycleException: Failed to initialize 
component [org.apache.catalina.webresources.JarResourceSet@38099cbe]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:113)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:140)
at 
org.apache.catalina.webresources.StandardRoot.startInternal(StandardRoot.java:724)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 9 more
Caused by: java.lang.IllegalArgumentException: java.util.zip.ZipException: 
invalid LOC header (bad signature)
at 
org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.initInternal(AbstractSingleArchiveResourceSet.java:113)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
... 12 more
Caused by: java.util.zip.ZipException: invalid LOC header (bad signature)
at java.util.zip.ZipFile.read(Native Method)
at java.util.zip.ZipFile.access$1400(Unknown Source)
at java.util.zip.ZipFile$ZipFileInputStream.read(Unknown Source)
at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(Unknown Source)
at java.util.zip.InflaterInputStream.read(Unknown Source)
at sun.misc.IOUtils.readFully(Unknown Source)
at java.util.jar.JarFile.getBytes(Unknown Source)
at java.util.jar.JarFile.getManifestFromReference(Unknown Source)
at java.util.jar.JarFile.getManifest(Unknown Source)
at 
org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.initInternal(AbstractSingleArchiveResourceSet.java:111)
... 13 more

Nov 19, 2017 2:30:30 PM org.apache.catalina.core.ContainerBase startInternal
SEVERE: A child container failed during start
java.util.concurrent.ExecutionException: