Return-Path: 
 <clerezza-dev-return-3711-apmail-incubator-clerezza-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-clerezza-dev-archive@minotaur.apache.org
Received: (qmail 65799 invoked from network); 2 Dec 2010 16:37:05 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 2 Dec 2010 16:37:05 -0000
Received: (qmail 87279 invoked by uid 500); 2 Dec 2010 16:37:05 -0000
Delivered-To: apmail-incubator-clerezza-dev-archive@incubator.apache.org
Received: (qmail 87151 invoked by uid 500); 2 Dec 2010 16:37:03 -0000
Mailing-List: contact clerezza-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:clerezza-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:clerezza-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:clerezza-dev@incubator.apache.org>
List-Id: <clerezza-dev.incubator.apache.org>
Reply-To: clerezza-dev@incubator.apache.org
Delivered-To: mailing list clerezza-dev@incubator.apache.org
Received: (qmail 87134 invoked by uid 99); 2 Dec 2010 16:37:03 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Dec 2010 16:37:03 +0000
X-ASF-Spam-Status: No, hits=1.5 required=10.0
	tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of tommaso.teofili@gmail.com
 designates 209.85.216.175 as permitted sender)
Received: from [209.85.216.175] (HELO mail-qy0-f175.google.com)
 (209.85.216.175)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Dec 2010 16:36:55 +0000
Received: by qyk8 with SMTP id 8so3915865qyk.6
        for <multiple recipients>; Thu, 02 Dec 2010 08:36:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:mime-version:received:in-reply-to
         :references:from:date:message-id:subject:to:cc:content-type;
        bh=/VVvM5kX8OLuCEyIa5+qH57wXM41b4GoWePkQUCdPsA=;
        b=OBkog6tHeQpRS9j6Y+LSkQLvVGjZPv3x1swDqcm4EM+N3CN2EXsrruq5J3PyyKDnw6
         mw8slXYbAR4IS5TT6bCizJ/LzCJv1gIgHcIwxtKjKs/d+iR6Zw56C9F2eGf7F/A4TpAP
         w71MSL6hNz8OGtpCbz1SfFFrCWX5zWqWRHw6E=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        b=nyP4Wk4/TZmCHe3P069UYkSWzUB2R5zZjAyR3vL9yEx0cN3jbnPSZZIeKhOwpShNpn
         sETk3tV0Kf01kar87cjPk0DGUIMWLaAN1zrtx0NDEKJCTfDcuWcUQmJvlz05A+SlsKAr
         4Cz0/6MDa4VicP1Uu2kUMr1I9nojE957+DnfM=
Received: by 10.229.236.66 with SMTP id kj2mr183389qcb.285.1291307794728; Thu,
 02 Dec 2010 08:36:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.222.80 with HTTP; Thu, 2 Dec 2010 08:36:14 -0800 (PST)
In-Reply-To: <1291305185.1467.5.camel@Nokia-N900-51-1>
References: <AANLkTi=02Me6rTDQb02_5nJz3NArg2JdoTs7Gg9RG-LY@mail.gmail.com>
 <1291305185.1467.5.camel@Nokia-N900-51-1>
From: Tommaso Teofili <tommaso.teofili@gmail.com>
Date: Thu, 2 Dec 2010 17:36:14 +0100
Message-ID: <AANLkTinG=cCN7VcboAKU=wq_4wsvkZhugo6VVKDYBU0r@mail.gmail.com>
Subject: Re: static logging and class/service loading
To: =?ISO-8859-1?Q?Reto_Bachmann=2DGm=FCr?= <reto.bachmann@trialox.org>
Cc: clerezza-dev@incubator.apache.org, stanbol-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016362840566689040496700609
X-Virus-Checked: Checked by ClamAV on apache.org

--0016362840566689040496700609
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=FCr <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 wit=
h
> > 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 outpu=
t
> > (e.g.: RDF+XML/JSON) so I chose Clerezza since I am familiar with it, i=
n
> > 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/ILoggerFa=
ctory;"
>
> > > 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 chos=
e
> > 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 nev=
er
>
> > fell into such a situation before, do you have ideas or already know ho=
w
> > we can prevent such an issue generally?
> >
> > Regards,
> > Tommaso
>
>

--0016362840566689040496700609--