incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommaso Teofili <tommaso.teof...@gmail.com>
Subject Re: static logging and class/service loading
Date Thu, 02 Dec 2010 16:36:14 GMT
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 <reto.bachmann@trialox.org>

>  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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message