Improving problem reporting
PROBLEM DESCRIPTION:
I have an exception (appended below), and I think it would be nice to
have more information about what is going on.
If I had more context, it would help me find the cause of my problem
much more quickly. For example, if the exception indicated what the
file/resource that was having the problem was, it would speed up
troubleshooting immensely.
HOW TO REPRODUCE:
In a JAR file contained in WAR file's WEB-INF/lib folder: Change the
MANIFEST.MF file in the JAR file. Put in a line with ONLY
"Class-Path:". Note there is no space after the period, which is what
causes the error. During load of the application, the exception which I
have appended at the end of this message will show up.
SUGGESTED IMPROVEMENT:
My suggestion would be to modify
ExtensionValidator.validateApplication(...), around line 195. This is
the location that actually knows about what the resource is. It would
be nice if the IOException was caught, and information about the
Resource was added to the exception, probably by wrapping the exception.
Because I have not gone through the overhead of getting a version of
Tomcat running from source, these changes have not been compiled and
tested, but I think the suggestion is relatively straight-forward.
Here are the suggested code changes:
First code change - move the definition of "resource" outside of the
try/catch:
// Locate the Manifests for all bundled JARs
Resource resource = null; // ADDED
NamingEnumeration ne = null;
Second code change - make the existing declaration of "resource" just an
assignment:
resource = (Resource) obj; // MODIFIED
inputStream = resource.streamContent();
Manifest jmanifest = getManifest(inputStream);
Third code change: add a catch clause and re-throw:
} catch (NamingException nex) {
// Jump out of the check for this application because it
// has no resources
} catch (IOException ioex) { // ADDED
throw new IOException("validation problem in " +
resource.toString(), ioex); // ADDED
} finally {
The problem is that the resource may not have a proper toString(). I
would suggest changing FileDirContext:898 (inner class=FileResource) to
have a toString method, something along the lines of:
public String toString() { // ADDED
return file == null ? "null" : file.toString(); // ADDED
} // ADDED
Finally, here's the exception:
28-Oct-2011 11:03:03 AM org.apache.catalina.core.StandardContext
startInternal
SEVERE: Error in dependencyCheck
java.io.IOException: invalid header field
at java.util.jar.Attributes.read(Attributes.java:410)
at java.util.jar.Manifest.read(Manifest.java:199)
at java.util.jar.JarInputStream.(JarInputStream.java:83)
at java.util.jar.JarInputStream.(JarInputStream.java:60)
at
org.apache.catalina.util.ExtensionValidator.getManifest(ExtensionValidator.java:394)
at
org.apache.catalina.util.ExtensionValidator.validateApplication(ExtensionValidator.java:195)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5037)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:148)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1033)
at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:774)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:148)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1033)
at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:291)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:148)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:443)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:148)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:727)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:148)
at org.apache.catalina.startup.Catalina.start(Catalina.java:621)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:450)
(And if only java.util.jar.Attributes.read reported WHICH attribute had
the problem, we'd really be in business.)
Regards,
Chris
--
The Time Is The Time!
Daylight Savings Time wastes energy and money
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomca
Re: Improving problem reporting
2011/10/28 Chris Dailey :
> PROBLEM DESCRIPTION:
>
> I have an exception (appended below), and I think it would be nice to have
> more information about what is going on.
>
> If I had more context, it would help me find the cause of my problem much
> more quickly. For example, if the exception indicated what the
> file/resource that was having the problem was, it would speed up
> troubleshooting immensely.
>
> HOW TO REPRODUCE:
>
> In a JAR file contained in WAR file's WEB-INF/lib folder: Change the
> MANIFEST.MF file in the JAR file. Put in a line with ONLY "Class-Path:".
> Note there is no space after the period, which is what causes the error.
> During load of the application, the exception which I have appended at the
> end of this message will show up.
>
> SUGGESTED IMPROVEMENT:
>
> My suggestion would be to modify
> ExtensionValidator.validateApplication(...), around line 195. This is the
> location that actually knows about what the resource is. It would be nice
> if the IOException was caught, and information about the Resource was added
> to the exception, probably by wrapping the exception.
>
> Because I have not gone through the overhead of getting a version of Tomcat
> running from source, these changes have not been compiled and tested, but I
> think the suggestion is relatively straight-forward.
>
> Here are the suggested code changes:
>
> First code change - move the definition of "resource" outside of the
> try/catch:
>
> // Locate the Manifests for all bundled JARs
> Resource resource = null; // ADDED
> NamingEnumeration ne = null;
>
> Second code change - make the existing declaration of "resource" just an
> assignment:
>
> resource = (Resource) obj; // MODIFIED
> inputStream = resource.streamContent();
> Manifest jmanifest = getManifest(inputStream);
>
> Third code change: add a catch clause and re-throw:
>
> } catch (NamingException nex) {
> // Jump out of the check for this application because it
> // has no resources
> } catch (IOException ioex) { // ADDED
> throw new IOException("validation problem in " +
> resource.toString(), ioex); // ADDED
> } finally {
>
> The problem is that the resource may not have a proper toString(). I would
> suggest changing FileDirContext:898 (inner class=FileResource) to have a
> toString method, something along the lines of:
>
> public String toString() { // ADDED
> return file == null ? "null" : file.toString(); // ADDED
> } // ADDED
>
> Finally, here's the exception:
>
> 28-Oct-2011 11:03:03 AM org.apache.catalina.core.StandardContext
> startInternal
> SEVERE: Error in dependencyCheck
> java.io.IOException: invalid header field
> at java.util.jar.Attributes.read(Attributes.java:410)
> at java.util.jar.Manifest.read(Manifest.java:199)
> at java.util.jar.JarInputStream.(JarInputStream.java:83)
> at java.util.jar.JarInputStream.(JarInputStream.java:60)
> at
> org.apache.catalina.util.ExtensionValidator.getManifest(ExtensionValidator.java:394)
> at
> org.apache.catalina.util.ExtensionValidator.validateApplication(ExtensionValidator.java:195)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5037)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:148)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1033)
> at
> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:774)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:148)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1033)
> at
> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:291)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:148)
> at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:443)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:148)
> at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:727)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:148)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:621)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:450)
>
> (And if only java.util.jar.Attributes.read reported WHICH attribute had the
> problem, we'd really be in business.)
>
Not sure about FileResource.toString(), but adding a catch for
IOException looks like doable.
Please file an enhancement issue
