Bug 45785 - ClassCastException if directory ending with .jar exists in WEB-INF/lib
ClassCastException if directory ending with .jar exists in WEB-INF/lib
Product: Tomcat 6
Classification: Unclassified
Component: Catalina
All All
: P2 normal (vote)
: default
Assigned To: Tomcat Developers Mailing List
Depends on:
  Show dependency tree
Reported: 2008-09-11 12:22 UTC by Andreas Sahlbach
Modified: 2014-02-17 13:51 UTC (History)
1 user (show)

Add support for directories with name ending on .jar (1.03 KB, patch)
2009-07-07 00:35 UTC, Rolf Wojtech
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Sahlbach 2008-09-11 12:22:35 UTC
Exception occurs if there is a directory in WEB-INF/lib having a .jar ending (e.g. foo.jar). Don't know if it makes sense to create such a dir in WEB-INF/lib, in my case a bug in another tool created such a dir. 

But in any case: Tomcat should not crash because of such a directory, IMHO.

java.lang.ClassCastException: org.apache.naming.resources.FileDirContext cannot be cast to org.apache.naming.resources.Resource
	at org.apache.catalina.util.ExtensionValidator.validateApplication(ExtensionValidator.java:182)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4167)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
	at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:627)
	at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
	at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
	at org.apache.catalina.core.StandardService.start(StandardService.java:516)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Comment 1 Mark Thomas 2008-09-14 13:03:54 UTC
This has been fixed in trunk and proposed for 6.0.x
Comment 2 Mark Thomas 2008-09-19 03:59:54 UTC
This has been fixed in 6.0.x and will be included in 6.0.19 onwards.
Comment 3 Rolf Wojtech 2009-07-07 00:35:40 UTC
Created attachment 23934 [details]
Add support for directories with name ending on .jar

While the specific case (directory called .jar in WEB-INF/lib) has been fixed, two other cases remain in ExtensionValidator.

Therefore I reopened this bug:

We're using an exploded deployment mechanism which uses extracted jar files in folders called jarname.jar. The eclipse projects build directly into those folders.
However when adding these projects to a jboss launch configuration, which results in a jarname.jar folder (not file) to be part of the classpath, JBoss will fail because ExtensionValidator tries to treat the jarname.jar folder as a file.
ExtensionValidator only checks if a java.io.File endsWith(".jar") but it fails to check if it is an actual file, not a directory.

I attached a proposed fix (I only added the !item.isDirectory() and !files[i].isDirectory() )

I ran into other JBoss problems after fixing this which means that this does not really affect me. It may not be popular to name directories something.jar but in the cases of exploded deployment this seems normal. In any case my patch does not affect the normal usage of actual .jar files so I see no reason not to include it.
Comment 4 Rolf Wojtech 2009-07-07 00:36:28 UTC
Reopened due to additional problems with directories called somename.jar
Comment 5 Mark Thomas 2009-09-09 09:21:46 UTC
I have fixed trunk and proposed the same fix for 6.0.x based on your patch.

Many thanks.
Comment 6 Mark Thomas 2009-10-03 10:35:29 UTC
This has been fixed in 6.0.21 and will be included in 6.0.21 onwards.

Thanks again for the patch.