commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Thomas" <Arun.Tho...@solidusnetworks.com>
Subject [validator][digester] Compressed parsing exception....
Date Wed, 16 Jul 2003 17:56:23 GMT
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


Mime
View raw message