search

GateNLP / gate-core

The GATE Embedded core API and GATE Developer application
GNU Lesser General Public License v3.0
75 stars 29 forks source link

NoSuchMethodError when 8.6 plugins try calling Utils.logOnce #123

Closed greenwoodma closed 3 years ago

greenwoodma commented 4 years ago

It looks as if I've managed to break backwards compatibility around the Utils.logOnce() method working on updating the logging in GATE. This is the error you get if you run the ANNIE POS tagger over an empty doc with failOnMissingAnnotations set to false and hit an empty document

Exception in thread "ApplicationViewer1" java.lang.NoSuchMethodError: gate.Utils.logOnce(Lorg/apache/log4j/Logger;Lorg/apache/log4j/Level;Ljava/lang/String;)V
    at gate.creole.POSTagger.execute(POSTagger.java:265)
    at gate.util.Benchmark.executeWithBenchmarking(Benchmark.java:293)
    at gate.creole.ConditionalSerialController.runComponent(ConditionalSerialController.java:172)
    at gate.creole.SerialController.executeImpl(SerialController.java:158)
    at gate.creole.ConditionalSerialAnalyserController.executeImpl(ConditionalSerialAnalyserController.java:225)
    at gate.creole.ConditionalSerialAnalyserController.execute(ConditionalSerialAnalyserController.java:132)
    at gate.util.Benchmark.executeWithBenchmarking(Benchmark.java:293)
    at gate.gui.SerialControllerEditor$RunAction$1.run(SerialControllerEditor.java:1777)
    at java.lang.Thread.run(Thread.java:748)

Ideally apps built with 8.6.x should still work in 9.0-SNAPSHOT (especially those using the ANNIE plugin) unless we specifically blacklist the plugin to force users to update (see #89)

greenwoodma commented 3 years ago

The fix for this was to go back to explicitly using Log4J in the gate.Utils.logOnce() method call (which is deprecated) so that plugins built against older versions of GATE can find the method and don't simply throw a NoSuchMethodError. I don't like this as it again means Log4J is a runtime dependency (technically it's the SLF4J bridge but still). but I can't see a way around this until we've fixed all our plugins which use Log4J, and even then we'd break any external plugins which used Log4J as well and we shouldn't blacklist a plugin simply because it uses the logging mechanism we previously recommended, or not yet anyway.