Hi Reto, I hadn't any compile time dependency from any static logger inside the FISE-Confluence integration code and only the slf4j-api dependency is at compile time in Clerezza; the only possibility could be a dependency like slf4j-log4j12 inside Confluence. I think the problem is when a SLF4J-logger-enabled module is living inside a class loader that is not the default/system (where SLF4J static logger binding works) and another static logger binder was already set. I tried "bypassing" the plugins' classloader deploying the plugin's libraries directly inside lib directory, instead of having them inside the plugin jar, and SLF4J logging didn't work but the LinkageError didn't show up; however this is not "clean" so I'd not suggest such a "brute force" way :-) Cheers, Tommaso
2010/12/2 Reto Bachmann-Gmür <[email protected]> > Hi Tommaso > > i think its a bug to have a compile time dependency on the static logger, > does the problem only occur if this is the case? > > Cheers, > reto > > > ----- Original message ----- > > 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 > >
