You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Tommaso Teofili <to...@gmail.com> on 2010/12/02 09:39:36 UTC
static logging and class/service loading
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
Re: static logging and class/service loading
Posted by Tommaso Teofili <to...@gmail.com>.
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 <re...@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
>
>
Re: static logging and class/service loading
Posted by Tommaso Teofili <to...@gmail.com>.
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 <re...@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
>
>
Re: static logging and class/service loading
Posted by Reto Bachmann-Gmür <re...@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
Re: static logging and class/service loading
Posted by Reto Bachmann-Gmür <re...@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