Achim Nierbeck
added a comment - 25/Aug/11 08:06 this is not entirely true since the webdeployer also is capable of handling exploded jars. This way it's not easy to check if this is really a "zip" file

Following does prevent this issue for beeing really fixable.
The WarDeployer canHandle method retrieves a File artifact.
This artifact is tried to be inspected by the JarFile class which is not applicable for
std. Files but for exploded Jar-files
The actual creation of JarFile(artifact) throws an exception since it is not a JarFile.
So the only way of fixing this is to set the loglevel for tracing the exception to TRACE.

If someone is in need for knowing the reason of failure on this part the loglevel must be set to TRACE for org.ops4j.pax.web.deployer.*

Achim Nierbeck
added a comment - 25/Aug/11 20:20 This issue is not really fixable.
Following does prevent this issue for beeing really fixable.
The WarDeployer canHandle method retrieves a File artifact.
This artifact is tried to be inspected by the JarFile class which is not applicable for
std. Files but for exploded Jar-files
The actual creation of JarFile(artifact) throws an exception since it is not a JarFile.
So the only way of fixing this is to set the loglevel for tracing the exception to TRACE.
If someone is in need for knowing the reason of failure on this part the loglevel must be set to TRACE for org.ops4j.pax.web.deployer.*