[validator][digester] Compressed parsing exception....

[Arun Thomas <Ar...@solidusnetworks.com>]

Folks, 

I'm writing because I'm running across a really strange bug which I cannot, for the life of me figure out.  Or rather, I know what's causing it, but I'm not sure why: I'm getting an exception when parsing an xml file (validation.xml) obtained as an input stream from the classpath within a compressed jar.    

The scenario...:  I've written a stand-alone application which I release as an application jar for invocation as a jar.  The jar file includes a validation.xml which is accessed as in input stream using ClassLoader.getResourceAsStream() and used as input to ValidatorResourcesInitializer in order to set up validation.  The validator process makes use of digester to read the xml, and right now, what I see is an exception raised by the parser and propagated through digester and validator while parsing the validation.xml.  

Now comes the strange part: it appears that this exception is only raised when the validation.xml within the jar file has been compressed.  Updating with a copy of the same file without compression resolved the problem.  Has anyone seen anything like this before?  (This may well have to do with the parser (xerces), as the exception is generated by the parser, but I thought it worth checking....)  

I've used jar to extract the validation file, and update the jar file using the extracted file but without compression - no error occurs.  Then I update the jar file once again (using the previously extracted file) with compression - the file compressed by about the same percentage as previously - and, once again, the exception occurs.  

How did I test for this?  First, the system details: I'm running on windows XP using cygwin as my command line.  (Ergo the strange mix between unix and windows notation in the following....)  I've tried invoking the program with both the sun jdk 1.4 and the ibm jdk 1.3 - the same problem occurs.  I eventually determined what the final problem with the following bash script:

  jar -xvf mems-ear.ear
  rm mems-ear.ear

  jar -tvf mems.jar >> /tmp/predecomp.txt
  zipinfo -v mems.jar >> /tmp/predecomp.txt
  java com.solidusnetworks.mems.ui.controller.Controller >> /tmp/predecomp.txt

  jar -xvf mems.jar com/solidusnetworks/mems/resources/validation.xml
  jar -uvf0 mems.jar com/solidusnetworks/mems/resources/validation.xml

  jar -tvf mems.jar >> /tmp/postdecomp.txt
  zipinfo -v mems.jar >> /tmp/postdecomp.txt
  java com.solidusnetworks.mems.ui.controller.Controller >> /tmp/postdecomp.txt

  jar -uvf mems.jar com/solidusnetworks/mems/resources/validation.xml

  jar -tvf mems.jar >> /tmp/postrecomp.txt
  zipinfo -v mems.jar >> /tmp/postrecomp.txt
  java com.solidusnetworks.mems.ui.controller.Controller >> /tmp/postrecomp.txt

  diff /tmp/predecomp.txt /tmp/postdecomp.txt >> /tmp/diffdecomp.txt
  diff /tmp/postdecomp.txt /tmp/postrecomp.txt >> /tmp/diffrecomp.txt

I attach as well the relevant results from the output files.  
  1) zipinfo.txt - Relevant sections of zipinfo output showing the change in validation.xml 
  2) appout.txt  - Initial application log output showing validator initialization  
In each file, the three sections are denoted by the following labels:
  A) Original File
  B) After Decompression of validation.xml
  C) After Recompression of validation.xml

Other libraries used:
  commons-beanutils.jar*
  commons-collections.jar*

  commons-digester.jar*
  commons-lang-1.0.1.jar*
  commons-logging-api.jar*

  commons-logging.jar*
  commons-validator-1.0.1-SOL-1.1.jar
    a version of validator edited to provide access to the results

  jakarta-oro-2.0.7.jar*
  jakarta-regexp-1.2.jar*
  mems-ejb.jar* 
    contains shared code with ejb backend
  mems.jar*
    contains application code
  util.jar*
  xercesImpl.jar*

  lib\j2ee.jar
  lib\log4j.jar
  lib\jbossall-client.jar
    needed to access jboss JDNI repository

If any of you have experienced something like this, I'd appreciate knowing.  The behaviour is quite strange to me.  

Cheers, 
-AMT