Hi all, just after my brief experience in integrating FISE with Confluence I'd like to share a deploying scenario that made me spend (waste?) a lot of time. Sorry for cross posting but I think it could be interesting for both projects. Just after developing a Confluence page listener which tagged pages with FISE generated entities and labels I tried to deploy it on a running Confluence (3.1.2); one thing I obviously needed was parsing FISE output (e.g.: RDF+XML/JSON) so I chose Clerezza since I am familiar with it, in particular I got JenaParserProvider since it's simple and straightforward. Everything was ok except that when deploying my plugin I got:
java.lang.LinkageError: loader constraint violation: when resolving method > "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" > the class loader (instance of > com/atlassian/plugin/classloader/PluginClassLoader) of the current class, > org/slf4j/LoggerFactory, and the class loader (instance of > org/apache/catalina/loader/WebappClassLoader) for resolved class, > org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type > org/slf4j/ILoggerFactory used in the signature this happened because of 2 different classloaders which had different SLF4J service loader configurations. After a bit of "fighting" I realized that the options to resolve it are - avoid static logger binding and use a non static one - disable slf4j logging I went to JenaParserProvider to check for SLF4J but then I realized logger was instantiated inside Jena code so, to make it shorter, I chose Clerezza RdfJsonParserProvider which had also a SLF4J logger that I could change directly and everything worked. So, in the end, I've been using SLF4J now for quite a long time and never fell into such a situation before, do you have ideas or already know how we can prevent such an issue generally? Regards, Tommaso
