Corrupted xlsx file on just one server

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Corrupted xlsx file on just one server

Seb Duggan

Hi POI people...

I'm seeing a very strange issue where .xlsx files generated via POI on our live server are corrupted, whereas on all dev and staging environments they work absolutely fine.

I created a minimal test case, where I create an empty org.apache.poi.xssf.usermodel.XSSFWorkbook (I'm using POI 3.16) with a single sheet called "Sheet1". I then send this to the user as a binary file.

I have attached the "good" and "bad" files. I opened up the .xlsx files to examine their contents and noticed the following differences in [Content_Type].xml:

GOOD:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Default ContentType="application/vnd.openxmlformats-package.relationships+xml" Extension="rels"/>
<Default ContentType="application/xml" Extension="xml"/>
<Override ContentType="application/vnd.openxmlformats-officedocument.extended-properties+xml" PartName="/docProps/app.xml"/>
<Override ContentType="application/vnd.openxmlformats-package.core-properties+xml" PartName="/docProps/core.xml"/>
<Override ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.sharedStrings+xml" PartName="/xl/sharedStrings.xml"/>
<Override ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.styles+xml" PartName="/xl/styles.xml"/>
<Override ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml" PartName="/xl/workbook.xml"/>
<Override ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.worksheet+xml" PartName="/xl/worksheets/sheet1.xml"/>
</Types>

BAD:

<?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>
<Types>
   <Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/>
   <Default Extension="xml" ContentType="application/xml"/>
   <Override PartName="/docProps/app.xml" ContentType="application/vnd.openxmlformats-officedocument.extended-properties+xml"/>
   <Override PartName="/docProps/core.xml" ContentType="application/vnd.openxmlformats-package.core-properties+xml"/>
   <Override PartName="/xl/sharedStrings.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.sharedStrings+xml"/>
   <Override PartName="/xl/styles.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.styles+xml"/>
   <Override PartName="/xl/workbook.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml"/>
   <Override PartName="/xl/worksheets/sheet1.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.worksheet+xml"/>
</Types>

Notice the differences in the first two lines...

There is a minimal difference in the Java version on the servers: my local computer is running 1.8.0_112, staging is running 1.8.0_45, and live (producing the corrupt files) is on 1.8.0_66. All are Oracle 64-bit.

Can anyone think of what might be causing the difference in output between the servers? I've been banging my head against this now for a couple of days!


Thanks,

Seb



--



Seb Duggan
Senior Developer

Pixl8 Interactive, 3 Tun Yard, 
Peardon Street, London, SW8 3HT
<a href="tel:020%207720%204545" value="+442077204545" target="_blank" style="color:rgb(17,85,204)">+44 (0) 207 720 4545

        

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Corrupted xlsx file on just one server

Nick Burch-2
On Thu, 7 Sep 2017, Seb Duggan wrote:
> Notice the differences in the first two lines...
>
> There is a minimal difference in the Java version on the servers: my local
> computer is running 1.8.0_112, staging is running 1.8.0_45, and live
> (producing the corrupt files) is on 1.8.0_66. All are Oracle 64-bit.
>
> Can anyone think of what might be causing the difference in output between
> the servers? I've been banging my head against this now for a couple of
> days!

My best guess is that on production, you have deliberately or accidentally
configured in a different (likely older / less functional) XML library as
your JVM-default XML handler

I'd suggest doing something like "SAXParserFactory.newInstance();" then
checking what class you got + which jar that class came from. My hunch is
they won't be the same on both servers, and likely won't be what you
wanted / expected on your broken server!

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Corrupted xlsx file on just one server

Seb Duggan
Thanks Nick.

Both staging and live are using "oracle.xml.jaxp.JXSAXParserFactory" from
exactly the same version of xmlparserv2.jar - but one works, while the
other doesn't.

Locally, I'm using "org.apache.xerces.jaxp.SAXParserFactoryImpl", from
apache-xml-xerces.jar - which works.

Both jars are available on all environments - where might any setting of
the default be taking place? This is on Tomcat; nothing seems to be
specified in sentenv.sh...


Seb



On 7 September 2017 at 11:40:07, Nick Burch ([hidden email]) wrote:

On Thu, 7 Sep 2017, Seb Duggan wrote:
> Notice the differences in the first two lines...
>
> There is a minimal difference in the Java version on the servers: my
local
> computer is running 1.8.0_112, staging is running 1.8.0_45, and live
> (producing the corrupt files) is on 1.8.0_66. All are Oracle 64-bit.
>
> Can anyone think of what might be causing the difference in output
between
> the servers? I've been banging my head against this now for a couple of
> days!

My best guess is that on production, you have deliberately or accidentally
configured in a different (likely older / less functional) XML library as
your JVM-default XML handler

I'd suggest doing something like "SAXParserFactory.newInstance();" then
checking what class you got + which jar that class came from. My hunch is
they won't be the same on both servers, and likely won't be what you
wanted / expected on your broken server!

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Corrupted xlsx file on just one server

Javen O'Neal
> xmlparserv2.jar
Did you compare the hashes of these jars to verify they truly are the same?

On Sep 7, 2017 04:34, "Seb Duggan" <[hidden email]> wrote:

Thanks Nick.

Both staging and live are using "oracle.xml.jaxp.JXSAXParserFactory" from
exactly the same version of xmlparserv2.jar - but one works, while the
other doesn't.

Locally, I'm using "org.apache.xerces.jaxp.SAXParserFactoryImpl", from
apache-xml-xerces.jar - which works.

Both jars are available on all environments - where might any setting of
the default be taking place? This is on Tomcat; nothing seems to be
specified in sentenv.sh...


Seb



On 7 September 2017 at 11:40:07, Nick Burch ([hidden email]) wrote:

On Thu, 7 Sep 2017, Seb Duggan wrote:
> Notice the differences in the first two lines...
>
> There is a minimal difference in the Java version on the servers: my
local
> computer is running 1.8.0_112, staging is running 1.8.0_45, and live
> (producing the corrupt files) is on 1.8.0_66. All are Oracle 64-bit.
>
> Can anyone think of what might be causing the difference in output
between
> the servers? I've been banging my head against this now for a couple of
> days!

My best guess is that on production, you have deliberately or accidentally
configured in a different (likely older / less functional) XML library as
your JVM-default XML handler

I'd suggest doing something like "SAXParserFactory.newInstance();" then
checking what class you got + which jar that class came from. My hunch is
they won't be the same on both servers, and likely won't be what you
wanted / expected on your broken server!

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Corrupted xlsx file on just one server

Seb Duggan
Yes, they are identical...


On 7 September 2017 at 16:24:27, Javen O'Neal ([hidden email]) wrote:

> xmlparserv2.jar
Did you compare the hashes of these jars to verify they truly are the same?

On Sep 7, 2017 04:34, "Seb Duggan" <[hidden email]> wrote:

Thanks Nick.

Both staging and live are using "oracle.xml.jaxp.JXSAXParserFactory" from
exactly the same version of xmlparserv2.jar - but one works, while the
other doesn't.

Locally, I'm using "org.apache.xerces.jaxp.SAXParserFactoryImpl", from
apache-xml-xerces.jar - which works.

Both jars are available on all environments - where might any setting of
the default be taking place? This is on Tomcat; nothing seems to be
specified in sentenv.sh...


Seb



On 7 September 2017 at 11:40:07, Nick Burch ([hidden email]) wrote:

On Thu, 7 Sep 2017, Seb Duggan wrote:
> Notice the differences in the first two lines...
>
> There is a minimal difference in the Java version on the servers: my
local
> computer is running 1.8.0_112, staging is running 1.8.0_45, and live
> (producing the corrupt files) is on 1.8.0_66. All are Oracle 64-bit.
>
> Can anyone think of what might be causing the difference in output
between
> the servers? I've been banging my head against this now for a couple of
> days!

My best guess is that on production, you have deliberately or accidentally
configured in a different (likely older / less functional) XML library as
your JVM-default XML handler

I'd suggest doing something like "SAXParserFactory.newInstance();" then
checking what class you got + which jar that class came from. My hunch is
they won't be the same on both servers, and likely won't be what you
wanted / expected on your broken server!

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Corrupted xlsx file on just one server

Greg Woolsey
The XML declaration, with the single quotes, looks a lot like this question
on SO:

https://stackoverflow.com/questions/43754776/java-transformer-adding-spaces-and-single-quotes-to-xml-header-and-not-encoding

The specific class generating the XML is
org.apache.poi.openxml4j.opc.StreamHelper, via
a javax.xml.transform.Transformer created from

javax.xml.transform.TransformerFactory.newInstance().newTransformer()

In my environment at least, this comes directly from rt.jar, no extra
libraries needed.  However, if some library in your environment is setting
a different one, that could be the cause.  Can you see which concrete class
is returned by that static method?


On Thu, Sep 7, 2017 at 9:43 AM Seb Duggan <[hidden email]> wrote:

> Yes, they are identical...
>
>
> On 7 September 2017 at 16:24:27, Javen O'Neal ([hidden email])
> wrote:
>
> > xmlparserv2.jar
> Did you compare the hashes of these jars to verify they truly are the same?
>
> On Sep 7, 2017 04:34, "Seb Duggan" <[hidden email]> wrote:
>
> Thanks Nick.
>
> Both staging and live are using "oracle.xml.jaxp.JXSAXParserFactory" from
> exactly the same version of xmlparserv2.jar - but one works, while the
> other doesn't.
>
> Locally, I'm using "org.apache.xerces.jaxp.SAXParserFactoryImpl", from
> apache-xml-xerces.jar - which works.
>
> Both jars are available on all environments - where might any setting of
> the default be taking place? This is on Tomcat; nothing seems to be
> specified in sentenv.sh...
>
>
> Seb
>
>
>
> On 7 September 2017 at 11:40:07, Nick Burch ([hidden email]) wrote:
>
> On Thu, 7 Sep 2017, Seb Duggan wrote:
> > Notice the differences in the first two lines...
> >
> > There is a minimal difference in the Java version on the servers: my
> local
> > computer is running 1.8.0_112, staging is running 1.8.0_45, and live
> > (producing the corrupt files) is on 1.8.0_66. All are Oracle 64-bit.
> >
> > Can anyone think of what might be causing the difference in output
> between
> > the servers? I've been banging my head against this now for a couple of
> > days!
>
> My best guess is that on production, you have deliberately or accidentally
> configured in a different (likely older / less functional) XML library as
> your JVM-default XML handler
>
> I'd suggest doing something like "SAXParserFactory.newInstance();" then
> checking what class you got + which jar that class came from. My hunch is
> they won't be the same on both servers, and likely won't be what you
> wanted / expected on your broken server!
>
> Nick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>