Error executing command 'OpCreateChecker': User-specified log class <class> cannot be found or is not useable.

[1gmar]

Hi Jshiell, after upgrading to the latest version I've noticed the following issue:

if a project has a file commons-logging.properties in its classpath with the following content defined:

org.apache.commons.logging.Log=de.hybris.platform.util.logging.CommonsHybrisLog4jWrapper

The checkstyle plugin fails with the following error:

Unexpected Exception Caught
The scan failed due to an exception: Error executing command 'OpCreateChecker': User-specified log class 'de.hybris.platform.util.logging.CommonsHybrisLog4jWrapper' cannot be found or is not useable.
Root cause:
User-specified log class 'de.hybris.platform.util.logging.CommonsHybrisLog4jWrapper' cannot be found or is not useable.
    org.apache.commons.logging.LogConfigurationException: User-specified log class 'de.hybris.platform.util.logging.CommonsHybrisLog4jWrapper' cannot be found or is not useable.
    at org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:804)
    at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:541)
    at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:292)
    at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:269)

It seems that the plugin picks up the logging config of the project. Is this expected?

Checkstyle Version: 10.0 Checkstyle Plugin Version: 5.62.0 IntelliJ IDEA 2021.3.2 (Community Edition) Build #IC-213.6777.52, built on January 28, 2022

Thank you for your support!

[jshiell]

Ooo that's nasty. We need to use the classpath of the target project as Checkstyle wants to see the class files of some classes, in particular Exceptions.

It'll need a bit of a think, maybe we can filter out properties files when doing this 🤔

[jshiell]

The good news - I can reproduce it in a test project. Checkstyle loads commons-logging, which then scans the classpath and hits this.

The bad news - since we're using URL class loaders it's not simple to fix, as we just give it the base locations of possible paths and delegate to Java's class loading to do the actual work. And, alas, some Checkstyle checks do require the project classpath (in particular exception classes).

I'll keep thinking...

[PutienkoEN]

Hi! Do you have some news? Also facing this issue, wondering if I can somehow fix it on the configuration level.

[jshiell]

No bright ideas at present, I fear. It means some very nasty and potentially dangerous classpath manipulation, unless someone comes up with a better solution. As such, I'm very wary of going anywhere near it.

[1gmar]

Hey @PutienkoEN , my current workaround is to just comment out that line from commons-logging.properties during development.

[jshiell]

I am, as usual, an idiot. There is a simple solution that solves it for me, at least - wrap the classloader and just ignore any requests for commons-logging.properties.

The fix is in 5.71.1 - please let me know if it doesn't work for you!

[1gmar]

Sorry for the delayed reply, can confirm that the issue has been resolved.

Thank you for your support!