Multiple errors

[Karen Goh]

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.

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: 
org.apache.catalina.LifecycleException: Failed to start component 
[StandardEngine[Catalina].StandardHost[localhost]]
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.StandardEngine.startInternal(StandardEngine.java:262)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 

Re: Supported callbacks in Tomcat JASPIC implementation

[Mark Thomas]

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.

> 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.

Mark


> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61777
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61778
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61779
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61780
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61781
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61782
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61783
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61784
> 
> All fixes are really very small.
> 
> Regards,
> Lazar
> 
> On Wed, Nov 8, 2017 at 5:51 PM, Lazar Kirchev 
> wrote:
> 
>> Yes, my mistake - 3.5, not 4.5. But the content is the same.
>>
>> Thanks Mark!
>>
>> On Wed, Nov 8, 2017 at 5:38 PM, Mark Thomas  wrote:
>>
>>> On 08/11/2017 12:00, Lazar Kirchev wrote:
 Hello,

 According to the JASSPIC spec version 1.1, chapter 4.5, The
>>> CallbackHandler
 should support CallerPrincipalCallback, GroupPrincipalCallback,
 PasswordValidationCallback, as well as CertStoreCallback,
 PrivateKeyCallback, SecretKeyCallback and TrustStoreCallback.
>>>
>>> Chapter 4 is the SOAP profile.
>>>
>>> You want to look at Chapter 3 which is the Servlet Container profile.
>>>
 However, in Tomcat 8.5.*
 org.apache.catalina.authenticator.jaspic.CallbackHandlerImpl supports
>>> only
 CallerPrincipalCallback and GroupPrincipalCallback. Are there any plans
>>> to
 add support for the others?
>>>
>>> There are no plans to extend the JASPIC implementation at this time.
>>>
>>> Patches welcome.
>>>
>>> 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: Supported callbacks in Tomcat JASPIC implementation

[Lazar Kirchev]

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? 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):

https://bz.apache.org/bugzilla/show_bug.cgi?id=61777
https://bz.apache.org/bugzilla/show_bug.cgi?id=61778
https://bz.apache.org/bugzilla/show_bug.cgi?id=61779
https://bz.apache.org/bugzilla/show_bug.cgi?id=61780
https://bz.apache.org/bugzilla/show_bug.cgi?id=61781
https://bz.apache.org/bugzilla/show_bug.cgi?id=61782
https://bz.apache.org/bugzilla/show_bug.cgi?id=61783
https://bz.apache.org/bugzilla/show_bug.cgi?id=61784

All fixes are really very small.

Regards,
Lazar

On Wed, Nov 8, 2017 at 5:51 PM, Lazar Kirchev 
wrote:

> Yes, my mistake - 3.5, not 4.5. But the content is the same.
>
> Thanks Mark!
>
> On Wed, Nov 8, 2017 at 5:38 PM, Mark Thomas  wrote:
>
>> On 08/11/2017 12:00, Lazar Kirchev wrote:
>> > Hello,
>> >
>> > According to the JASSPIC spec version 1.1, chapter 4.5, The
>> CallbackHandler
>> > should support CallerPrincipalCallback, GroupPrincipalCallback,
>> > PasswordValidationCallback, as well as CertStoreCallback,
>> > PrivateKeyCallback, SecretKeyCallback and TrustStoreCallback.
>>
>> Chapter 4 is the SOAP profile.
>>
>> You want to look at Chapter 3 which is the Servlet Container profile.
>>
>> > However, in Tomcat 8.5.*
>> > org.apache.catalina.authenticator.jaspic.CallbackHandlerImpl supports
>> only
>> > CallerPrincipalCallback and GroupPrincipalCallback. Are there any plans
>> to
>> > add support for the others?
>>
>> There are no plans to extend the JASPIC implementation at this time.
>>
>> Patches welcome.
>>
>> Mark
>>
>>
>> -
>> 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?

[Alex O'Ree]

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.

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:
>
>
> -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