I don't see why DocumentHelper shouldn't be able to call POILogger, and I haven't noticed any issues with it elsewhere. Are you able to put together a small junit test case that triggers this IllegalAccessError?

Based on the comments in the code, we're trying the JDK built-in one first, as that's what we think most people are more likely to be using. It tries the other one if not, so you shouldn't miss out!

Ok, you are right, order should be ok. 

To keep things simple, put a line before the return statement. 

logger.log(POILogger.INFO, "SAX Security Manager setup"); 

If you see the changed method signature, all should clear, or not?

Kind regards,
Andreas

I added your logger statement to just before the return statement, and re-ran several of the XSSF unit tests. The logger statement worked just fine

I tried a bit more debugging and think I found it. 

Inspecting the NullLogger object, which is returned in the DocumentHelper

 private static POILogger logger = POILogFactory.getLogger(DocumentHelper.class);

there is a missing @Override annotation for the method public void log(int level, Object obj1, final Throwable exception): 

   /**
     * Log a message
     *
     * @param level One of DEBUG, INFO, WARN, ERROR, FATAL
     * @param obj1 The object to log.
     */

    @Override
    public void log(final int level, final Object obj1)
    {
        // do nothing
    }

    /**
     * Log a message
     *
     * @param level One of DEBUG, INFO, WARN, ERROR, FATAL
     * @param obj1 The object to log.  This is converted to a string.
     * @param exception An exception to be logged
     */
    public void log(int level, Object obj1, final Throwable exception) {
        // do nothing
    }

For probably that reason, the abstract method from the POILogger is called and the exception reflecting it: 

Caused by: java.lang.IllegalAccessError: tried to access method org.apache.poi.util.POILogger.log(ILjava/lang/Object;Ljava/lang/Throwable;)V from class org.apache.poi.util.DocumentHelper
	at org.apache.poi.util.DocumentHelper.trySetXercesSecurityManager(DocumentHelper.java:84)
	at org.apache.poi.util.DocumentHelper.<clinit>(DocumentHelper.java:57)


Try using it with a call before the return should prove it (where t can be null for testing purpose): 

logger.log(POILogger.WARN, "SAX Security Manager - test logger", t);

BTW the older 3.12 version of the NullLogger class has the annotation above the method. 

Can you confirm?

Kind regards, 
Andreas

Ok, I downloaded the 3.14 source from here:

https://www.apache.org/dyn/closer.lua/poi/release/src/poi-src-3.14.tar.gz

I did a few changes in 2 class files and compiled the source with Java 8, 32 bit. 

Fix 1)
To fix the IllegalAccessError, the abstract methods in the POILogger class are changed to public instead of protected:

abstract public void log(int level, Object obj1);
abstract public void log(int level, Object obj1, final Throwable exception);

Fix 2)

Put the @Override annotation above the method: 

@Override 
    public void log(int level, Object obj1, final Throwable exception) {
        // do nothing
    }

I don't think those two changes should make a difference, @override is a pure compile-time thing and not reflected in the bytecode in the .class/.jar file. Also protected should be fine and iwould usually fail during compile time if access is too strict.

Can you try to recompile the sources in their original state and see if that alone alreafy makes it work.

You might be right, but in that real case the IllegalAccess error is gone. 
The application server run with Java 1.8.0_72 and a JRE runtime error happens - probably a Oracle bug or a desired behaviour for such kind of declaration (abstract protected and override it with public).
 
There is nothing special I did, and I can't provide you a simple TestCase. As I mententioned before - try a logging with the method signature of the throwable and see yourself with Java 8. 

Kind regards,
Andreas

Please consider 

- the runtime is Java 8 in a JBoss 6 server environment

- the POILogger class in the DocumentHelper has no public log method (it is protected) - that leads to an IllegalAccess exception: 

private static POILogger logger = POILogFactory.getLogger(DocumentHelper.class);

Please change methods to public in POILogger and the thrill is gone:

abstract public void log(int level, Object obj1);
abstract public void log(int level, Object obj1, final Throwable exception);

Anyone got a work around on this ? Running Iseries ( as400;systemi;whatever ibm wants to call it ).

I think I have fixed this in r1761662. The problem is that the signature of log(int, Object...) is identical to log(int, Object) or log(int, Object, final Throwable). We are relying on the visibility of the last two to make the log(int, Object...) the version that gets called.
Looking at the code, Java must prefer non-varargs over varargs functions when the signature is otherwise compatible, which is why Andreas had issues with NullLogger calling the log methods that were protected in POILogger but public in NullLogger.

We are silently falling back to using a NullLogger for the DocumentHelper class, hopefully because the org.apache.poi.util.POILogger system property has not been set and not a different reason. POILogFactory [1] seems to be catching and suppressing exceptions in multiple locations.

Could you verify this fix with the latest trunk release?

[1] POILogFactory https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogFactory.java?view=log

I fixed the accidental accessibility elevation from protected to public in the remaining logging classes in r1761665.

This does not introduce any backwards compatibility issues because log(int, Object...) is still public and will catch any of the old uses.

(In reply to Javen O'Neal from comment #10)
> I think I have fixed this in r1761662. The problem is that the signature of
> log(int, Object...) is identical to log(int, Object) or log(int, Object,
> final Throwable). We are relying on the visibility of the last two to make
> the log(int, Object...) the version that gets called.
> Looking at the code, Java must prefer non-varargs over varargs functions
> when the signature is otherwise compatible, which is why Andreas had issues
> with NullLogger calling the log methods that were protected in POILogger but
> public in NullLogger.
> 
> We are silently falling back to using a NullLogger for the DocumentHelper
> class, hopefully because the org.apache.poi.util.POILogger system property
> has not been set and not a different reason. POILogFactory [1] seems to be
> catching and suppressing exceptions in multiple locations.
> 
> Could you verify this fix with the latest trunk release?
> 
> [1] POILogFactory
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/
> POILogFactory.java?view=log

Sorted downloaded the beta1 release 3.16 problem gone Thanks !!!

@backwards compatibility: this is backwards compatible with any class using a logger, but not for classes subclassing POI logger. They will need to change log to _log and optionally drop the accessibility to protected.