And all, here is even more information.
It is definitely something in Java and it's apparently inside the
cache/garbage. How do we know?
1) Open X4U.bat installed in the RenderX directory
2) Run X4U.bat and pick a simple example from the RenderX installed
directory that does not exhibit this issue, like adobe-standard.fo
3) Run it. It will work.
4) Now *without closing the Java session (i.e. leave x4u.bat open)*,
pick your "bad" file (if you have one as many work)
5) It will work without error
So to add to the below, this only seems to happen in a Java session if you
have not run a successful document through. One workaround is to use
X4U.bat to run your files, just run a simple example after opening it before
you run another document.
Crazy behavior but more material for our dev team to pursue the root cause
in the Java environment.
Kevin Brown
RenderX
From: xep-support-bounces@renderx.com
[mailto:xep-support-bounces@renderx.com] On Behalf Of Kevin Brown
Sent: Monday, February 21, 2011 1:02 PM
To: 'Dave Bickford'; 'RenderX Community Support List'
Subject: [xep-support] Re: FW: [renderx #22766] unstable validation errors
in Win7/2008 @ x64 JRE
Dave:
Good question. So that everyone knows ...
There is apparently an issue that exists/was introduced in 64-bit Java,
version 1.6.0_23 and later that "sometimes" "randomly" drop attribute values
in the tree when parsing that tree into the XT parser for Validation of the
XSL FO content only. It does seem to happen to some documents - we have also
run many on the
So, the only time you may see it is when:
1) You have the above 64-bit Java installed or later and you are using
it
2) You are running XEP and validating the XSL FO
It manifests in errors that may appear like . margin left cannot have a
value of "" .
If you run a transform and send the FO to disk, you will (likely) not find
anything like margin-left="" in your document. I say "likely" because you
could obviously have a bad template but that is not the issue. Somewhere in
Java in this process, the attributes are getting "lost" but only when
passing the objects for validation. They exist in the document tree and if
run, it will format just fine.
We'll do some analysis and report findings to Sun. In update 23, there were
changes in this area that likely broke something. I will point out that this
happened before in compression and it took several months for the folks at
Sun/Oracle to address it so no promises. We'll also try to investigate any
workaround for this but we cannot certainly fix Java.
Workarounds:
1) Turn off validation (set VALIDATE to "false")
2) Leave validation on but also set DISCARD_IF_NOT_VALID to "false",
take note of the errors and if any are empty attributes, it is likely not an
error in your template
3) Run either 32-bit Java or an earlier 64-bit Java (you can patch an
earlier version for the security issue only, see Oracle web site)
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_
US/-/USD/ViewProductDetail-Start?ProductRef=fpupdater-oth-JPR@CDS-CDS_Develo
per
4) Run your FO to disk and then use an alternate validation method like
opening in oXygen
Kevin Brown
RenderX
From: Dave Bickford [mailto:dbickford@sampletechnologies.com]
Sent: Monday, February 21, 2011 7:30 AM
To: kevin@renderx.com; RenderX Community Support List
Subject: Re: [xep-support] Re: FW: [renderx #22766] unstable validation
errors in Win7/2008 @ x64 JRE
I updated to
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
I am not experiencing any issues as far as I can determine. I use XEP from
within a java application with Saxon 6.5.5, but have also tried calling the
default XEP.bat (which used the RenderX suppied jars). For the life of me I
cannot find any issues.
Is this bug in java limited to certain xsl/fo/xpath constructs?
Does this bug occur using any of the RenderX supplied examples?
- Dave Bickford
On 2/18/2011 6:01 PM, Kevin Brown wrote:
OK. I have enough . it occurred in 23 I believe.
Michael: 1.6.0_24 - failure
Jan: I believe you have 1.6.0_23 - failure
Tobias: ?
David: ?
Kevin2: 1.6.0_22 - working
Kevin: 1.6.0_20 - working
Michael2: 1.6.0_19 - working
I would recommend rolling back your 64-bit Java installation to 1.6.0_22 and
all will work. We will examine the issue and see if there isn't some
patching we can do on our side. But again, this is looking purely like a
Java problem.
Kevin Brown
RenderX
From: xep-support-bounces@renderx.com
[mailto:xep-support-bounces@renderx.com] On Behalf Of Kevin Brown
Sent: Friday, February 18, 2011 2:43 PM
To: 'RenderX Community Support List'
Subject: [xep-support] Re: FW: [renderx #22766] unstable validation errors
in Win7/2008 @ x64 JRE
Please note, if you are getting us the version, only trust running;
java -version
in the exact directory to ensure you are getting the exact one (64bit).
Kevin
From: xep-support-bounces@renderx.com
[mailto:xep-support-bounces@renderx.com] On Behalf Of Kevin Brown
Sent: Friday, February 18, 2011 2:29 PM
To: 'RenderX Community Support List'; bradbury@renderx.com; 'Michael
Sulyaev'
Cc: 'David Ochel'
Subject: [xep-support] Re: FW: [renderx #22766] unstable validation errors
in Win7/2008 @ x64 JRE
OK.
Michael Bradbury and I have a machine that replicates the error (and one
that does not).
The most glaring difference is that the version of Java. I believe this is
pure Java bug caused somewhere between release 21 and 23.
23 had changes to sax.
Michael's (not working):
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
(document [system-id file:/N:/RX <file:///N:\RX> VDPMill Demos/XEP 64-BIT
(Jan Tosovsky)/bu_kronika-a.fo]
(validate
[error] Attribute 'margin-left' cannot have a value of "".
[validation total: 1 error]
Parse error: Invalid XSL FO source 'file:/N:/RX <file:///N:\RX> VDPMill
Demos/XEP 64-BIT (Jan Tosovsky)/bu_kronika-a.fo': 1 error found during
validation
My computer (working):
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
(document [system-id file:/C:/Program <file:///C:\Program> Files
(x86)/RenderX/XEP/bu_kronika.fo]
(validate [validation OK])
(compile
(masters
(sequence-master [master-name blank])
(sequence-master [master-name titlepage-first])
(sequence-master [master-name titlepage-odd])
(sequence-master [master-name titlepage-even])
(sequence-master [master-name lot-first])
(sequence-master [master-name lot-odd])
(sequence-master [master-name lot-even])
.
Those that see this problem, please report back the version of Java you
running so we can try and narrow a bit further to the exact version that
causes this failure.
Michael: 1.6.0_24 - failure
Jan: I believe you have 1.6.0_23 - failure
Tobias: ?
David: ?
Kevin: 1.6.0_20 - working
Kevin
From: xep-support-bounces@renderx.com
[mailto:xep-support-bounces@renderx.com] On Behalf Of Alejandro Masino
Sent: Thursday, February 17, 2011 4:23 PM
To: bradbury@renderx.com
Cc: 'David Ochel'; xep-support@renderx.com
Subject: [xep-support] [SPAM] Re: FW: [renderx #22766] unstable validation
errors in Win7/2008 @ x64 JRE
Michael, David:
We are not using Xalan. We are using Saxon 9 (jar obtained from
Saxonica/Source Forge) as our transformation engine, which takes precedence
in the classpath from the XEP lib directory.
Apparently, the saxon.jar bundled in XEP has less functionality than ours
(some XPATH related errors appear).
So far, we have done the PDF generation in a single step using an XSLT using
saxon9.jar, in Windows 32-bit and Linux without problems. The problem
appears in 64-bit, but I'm not sure where the problem is.
Using the XEP saxon.jar is not an option in the current generation
mechanism. I've downloaded the last version of saxon (saxon HE 9.3.0.4j),
but I've got errors in the PDF generation even in 32-bit:
[java] error: formatting failed: java.lang.NullPointerException: Null
content handler
or
(document [system-id
file:/T:/development/cctool/cctool-dev/trunk/project-samples/bsi23/ase/ese01
.fo
<file:///T:%5Cdevelopment%5Ccctool%5Ccctool-dev%5Ctrunk%5Cproject-samples%5C
bsi23%5Case%5Cese01.fo> ]
[java] Parse error: Null content handler
A workaround for the moment might be to split the generation process in two
steps, first generate a interim FO file using our transformation sheet with
saxon 9, and then generating the PDF with the bundled saxon.jar (which I
believe it works based on your tests on xep.bat).
So to summarize:
- What's the difference between the bundled saxon.jar with the saxon9.jar
you can obtain from Saxonica/Source Forge (XPATH?)
- I would believe that the problem then is in the saxon9.jar in 64-bit
platforms... but the new version does not work either
Thanks,
Alejandro
On 2/16/2011 10:22 AM, Michael Bradbury wrote:
David,
Before sending the FO file we ask that you provide:
1. Both ant script processes, the ant-controlled PDF generation and the
version that generates the FO file.
2. Search your complete machine for xep.xml to make sure you don't have more
than one copy. If you do have more than one please send by renaming them to
identify which is which.
4. Search your complete machine for xep.bat to make sure you don't have more
than one copy. If you do have more than one please send by renaming them to
*.txt and identify which is which.
3. Which XML to XSL FO transformer are you using?
As to determining which transformer you are using in my xep.bat the
statement:
set CP=C:\Program Files (x86)\RenderX\XEP\lib\xep.jar;C:\Program Files
(x86)\RenderX\XEP\lib\saxon.jar;C:\Program Files
(x86)\RenderX\XEP\lib\xt.jar
contains 'saxon.jar' as the transformer.
Regards,
Michael Bradbury
Dir Major Accounts, Bus Development
the future of YOUR document is here
RenderX, Inc.
The future of YOUR document is here
+1 (619) 692-9698 Direct & Voice Mail (San Diego, CA, USA)
+1 (650) 327-1000
+1 (650) 328-8008 Fax
Skype: brad765
bradbury@renderx.com
sales@renderx.com
http://www.renderx.com
-----Original Message-----
From: David Ochel [mailto:david@atsec.com]
Sent: Tuesday, February 15, 2011 3:40 PM
To: bradbury@renderx.com
Cc: Alejandro Masino
Subject: Re: FW: [renderx #22766] unstable validation errors in Win7/2008 @
x64 JRE
Hi Michael,
Thanks for your and Kevin's time. Here is some news:
1. I have been able to generate a basic document that fails as described and
doesn't contain any of our customer's information. So if you wanted I could
send you our NDA template to sign and I could then share a FO with you.
HOWEVER:
2. Running our "normal" ant-controlled PDF generation process with
validation set to true, the generation fails with a validation error. But if
I cause our framework to generate a FO file instead, and then run 'xep.bat
foo.fo', it validates fine and generates a PDF file fine. And this with both
32-bit or 64-bit Java!
So, it appears that I need to figure out what the difference is between
invoking xep via xep.bat and invoking it via our ant framework. I've copied
Alejandro, who is our framework mastermind, as I've no clue how to go about
that... ;-)
Cheers,
David
Michael Bradbury said the following on 2/15/2011 5:18 PM:
Hi David,
Thank you for your time today.
Since I have Sun Java 32 and 64-bit installed, and XEP is installed in
C:\Program Files (x86)\RenderX\XEP, I have two variations of my
xep.bat file, one calls Java 32 and the other Java 64.
My xep.bat that calls Java 32 consist of:
@echo off
rem This batch file encapsulates a standard XEP call.
set CP=C:\Program Files (x86)\RenderX\XEP\lib\xep.jar;C:\Program Files
(x86)\RenderX\XEP\lib\saxon.jar;C:\Program Files
(x86)\RenderX\XEP\lib\xt.jar
if x%OS%==xWindows_NT goto WINNT
"C:\Program Files (x86)\Java\jre6\bin\java" "-Xmx1024M" -classpath "%CP%"
com.renderx.xep.XSLDriver "-DCONFIG=C:\Program Files
(x86)\RenderX\XEP\xep.xml" %1 %2 %3 %4 %5 %6 %7 %8 %9 goto END
:WINNT
"C:\Program Files (x86)\Java\jre6\bin\java" "-Xmx1024M" -classpath "%CP%"
com.renderx.xep.XSLDriver "-DCONFIG=C:\Program Files
(x86)\RenderX\XEP\xep.xml" %*
:END
set CP=
===============================
My xep64.bat that calls Java 64 consist of:
@echo off
rem This batch file encapsulates a standard XEP call.
set CP=C:\Program Files (x86)\RenderX\XEP\lib\xep.jar;C:\Program Files
(x86)\RenderX\XEP\lib\saxon.jar;C:\Program Files
(x86)\RenderX\XEP\lib\xt.jar
if x%OS%==xWindows_NT goto WINNT
"C:\Program Files\Java\jre6\bin\java" "-Xmx8192M" -classpath "%CP%"
com.renderx.xep.XSLDriver "-DCONFIG=C:\Program Files
(x86)\RenderX\XEP\xep.xml" %1 %2 %3 %4 %5 %6 %7 %8 %9 goto END
:WINNT
"C:\Program Files\Java\jre6\bin\java" "-Xmx8192M" -classpath "%CP%"
com.renderx.xep.XSLDriver "-DCONFIG=C:\Program Files
(x86)\RenderX\XEP\xep.xml" %*
:END
set CP=
===============================
You will note the differences are:
- "C:\Program Files (x86)\Java\jre6\bin\java" vs. "C:\Program
Files\Java\jre6\bin\java"
- "-Xmx1024M" vs. "-Xmx8192M" (NOTE: 32-bit maximum value is 1024M
[M=mbytes]. You don't need 1024M given the size of the document's page
count. The Xmx value should not exceed 75% of the actual RAM (memeory)
in your machine).
- The remaining statements assume XEP was installed in C:\Program
Files (x86)\RenderX\XEP\
Regards,
Michael Bradbury
Dir Major Accounts, Bus Development
the future of YOUR document is here
RenderX, Inc.
The future of YOUR document is here
+1 (619) 692-9698 Direct & Voice Mail (San Diego, CA, USA)
+1 (650) 327-1000
+1 (650) 328-8008 Fax
Skype: brad765
bradbury@renderx.com
sales@renderx.com
http://www.renderx.com
-----Original Message-----
From: David Ochel (via Support) [mailto:support-team@renderx.com]
Sent: Tuesday, February 15, 2011 2:09 PM
Cc: support-staff@renderx.com
Subject: Re: [renderx #22766] unstable validation errors in Win7/2008
@ x64 JRE
Hi Michael,
Michael Sulyaev (via Support) said the following on 2/11/2011 5:09 PM:
This is the dedicated support list. When replying please preserve the
[renderx #22766] pattern on the subject line.
I need to reproduce the issue in proper environment first of all, so
please send a FO file where you observe unstable validation errors.
Working with proprietary customer data here, so this will be difficult.
David,
what is your XEP version?
Version 4.18 build 20101125
I think I'll just find a Win7/2008 x64 machine and install x64 JDK
from Sun there, play around and expect your FO files.
Let me know whether you get anywhere with the FO files from Jan and
Tobias.
If not, I need to take some time to strip confidential data from one
of mine. I'm very short on time right now, though.
Spotting the reason would not take long if it is in XEP. But I am
afraid it may happen to be between Java and XEP, which is worse.
Thanks, I really appreciate your help!
Cheers,
David
-- David Ochel, atsec information security mailto:david@atsec.com - http://www.atsec.com - tel:+1.512.615.7376 -- David Ochel, atsec information security mailto:david@atsec.com - http://www.atsec.com - tel:+1.512.615.7376 -- ______________________________________________________ Alejandro Fabio Masino atsec information security Visit our web-site at: www.atsec.com @sec: the information security provider Project=General ***SPAM*** !DSPAM:87,4d5dbbf963737522915389! _______________________________________________ (*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support (*) By using the Service, you expressly agree to these Terms of Service http://w ww.renderx.com/terms-of-service.html
_______________________________________________
(*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support
(*) By using the Service, you expressly agree to these Terms of Service http://w
ww.renderx.com/terms-of-service.html
Received on Mon Feb 21 13:08:12 2011
This archive was generated by hypermail 2.1.8 : Mon Feb 21 2011 - 13:08:13 PST