Error running PDF transformation in recent Oxygen

[martindholmes]

Hi all,

Running the oxygen-tei plugin's "jTEI PDF" transformation to turn a jTEI article into a PDF, we see this error:

Code: Select all

transform-fo:
     [java] ERROR StatusLogger Could not register mbeans
     [java]  java.security.AccessControlException: access denied ("javax.management.MBeanTrustPermission" "register")
     [java] 	at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
     [java] 	at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:444)
     [java] 	at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(DefaultMBeanServerInterceptor.java:1805)
     ...

This seems to be a security policy issue, but I'm not sure how we might solve it. Can anyone help?

Cheers,
Martin

[Ron Van den Branden]

Hi all,

Thanks for raising the issue here, Martin. Perhaps it could help to know that this is an ANT transformation scenario, which invokes an XSLT transformation via Java. This is the failing ANT task:

Code: Select all

  <target name="transform-fo">
    <delete file="${cfd}/${dest.file.basename}.fo"/>
    <java classname="net.sf.saxon.Transform">
      <arg value="-target:HE"/>
      <arg value="-s:${cfd}/${cfne}"/>
      <arg value="-xsl:${transformations.base}/pdf/to.xsl"/> 
      <arg value="-o:${cfd}/${dest.file.basename}.fo"/>
    </java>
  </target>

Best,

Ron

[martindholmes]

I see the libs include:

${oxygenHome}/lib/fop.jar

but Oxygen now includes:

oxygen-patched-fop.jar

Ditto for jeuclid-core and others; but we do include

${oxygenHome}/lib/*fop*.jar

Could it be the duplicate references? Or is this something to do with this lib:

${framework(TEI P5)}/xml/tei/jtei_aux/trans/pdf/lib/fontbox-*.jar

[Ron Van den Branden]

Hi Martin,

Could it be the duplicate references? Or is this something to do with this lib:

${framework(TEI P5)}/xml/tei/jtei_aux/trans/pdf/lib/fontbox-*.jar

That would surprise me:

• These duplicate entries have always existed, in order to improve compatibility with older Oxygen versions, and have never posed a problem before.

• The error also seems to occur with other ANT targets invoking the <java> task

IIRC, I believe this exact transformation used to run in my Oxygen-22 version in the past, while it is now throwing this error. Given this sudden change in behaviour, I suspect the only thing that may have changed is probably the Java version on my machine. If I'm interpreting this correctly, these <java> ANT tasks invoke the Java program on the computer; not the one shipped with Oxygen. If anything has changed to the security settings in recent Java updates, that might provide a plausible explanation. Though that would be rather annoying, since that Java version lies outside our control...

If this analysis is correct,

• what could be a practicable solution

• or, would there be a way to make ANT invoke the Java version shipped with Oxygen?

Best,

Ron

[Ron Van den Branden]

Ok, after a bit of tinkering I seem to have found a workaround or solution, by specifying that the <java> task should be executed in a forked JVM, which is running as a clone of the JVM running ANT. In concrete: the transformation does succeed when the <java> task is being specified as folows (notice the @fork and @clonevm attributes):

Code: Select all

  <target name="transform-fo">
    <delete file="${cfd}/${dest.file.basename}.fo"/>
    <java classname="net.sf.saxon.Transform" fork="true" clonevm="true">
      <arg value="-target:HE"/>
      <arg value="-s:${cfd}/${cfne}"/>
      <arg value="-xsl:${transformations.base}/pdf/to.xsl"/> 
      <arg value="-o:${cfd}/${dest.file.basename}.fo"/>
    </java>
  </target>

If this makes sense as a generally working solution, I can change the ANT build files for the jTEI transformations in the TEI framework accordingly. Unless there are better solutions?

Best,

Ron

[alex_jitianu]

Hello,

Thank you all for all the detective work. First of all, the exception is harmless.

If you take a look at org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(MBeanServer), you'll notice how it catches the exception, logs it, and moves forward without JMX support. The log4j JMX support allows one to connect and control the logging system. It is not something that we ever intended to use. We can edit the JTEI PDF scenario and add this property in the JVM Arguments field: -Dlog4j2.disable.jmx=true and the exception will no longer appear.

Alternatively, one could set the system property in the build file {frameworksDir}\tei\xml\tei\jtei_aux\trans\pdf\jtei-pdf.xml:

Code: Select all

<java classname="net.sf.saxon.Transform">
      <sysproperty key="log4j2.disable.jmx" value="true"/>
      <arg value="-target:HE"/>
      <arg value="-s:${cfd}/${cfne}"/>
      <arg value="-xsl:${transformations.base}/pdf/to.xsl"/> 
      <arg value="-o:${cfd}/${dest.file.basename}.fo"/>
    </java>

Best regards,
Alex

[Ron Van den Branden]

Many thanks Alex, I confirm this has solved the issue!

Best,

Ron