You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Raymond Auge <ra...@liferay.com> on 2018/10/01 16:42:18 UTC

Re: Felix Logback with logback >= 1.3.0-alpha4

I'm not sure I can agree with your position on the use of Service Loader
Mediator.

We, as an OSGi community, have no choice but to make certain accommodations
for the development of libraries which are not always going to be used in
OSGi but DO want to support it in the least intrusive way. Service Loader
Mediator is exactly that way.

All, I can suggest is to have a little faith. Aries Spi-Fly is a well used
and very efficient piece of software that does the absolute minimal amount
of bytecode manipulation. With the most recent release you can even get
around ordering issues by using the framework extension (also it's only a
single bundle with no dependencies) on an R7 framework (both of equinox and
felix have R7 releases).

<dependency>
  <groupId>org.apache.aries.spifly</groupId>

<artifactId>org.apache.aries.spifly.dynamic.framework.extension</artifactId>
  <version>1.0.14</version>
</dependency>

- Ray

On Sat, Sep 29, 2018 at 3:09 PM Mark Raynsford
<li...@io7m.com.invalid> wrote:

> Hello.
>
> The new generation of logback is modularized in the JPMS sense, and
> uses services (ServiceLoader) to find logging implementations.
>
> This means if you try to use a reasonably new version of logback with
> Felix Logback, you'll see this sort of thing:
>
> [ERROR] Resolution failed. Capabilities satisfying the following
> requirements could not be found:
>     [<<INITIAL>>]
>       ⮡ osgi.identity: (osgi.identity=org.apache.felix.logback)
>           ⮡ [org.apache.felix.logback version=1.0.0]
>               ⮡ osgi.wiring.package:
> (&(osgi.wiring.package=ch.qos.logback.classic.spi)(&(version>=1.2.0)(!(version>=2.0.0))))
>                   ⮡ [ch.qos.logback.classic version=1.3.0.alpha4]
>                       ⮡ osgi.extender:
> (osgi.extender=osgi.serviceloader.registrar)
>
> It seems that it's now required to use something like Aries SPI Fly
> (the reference implementation of the OSGi ServiceLoader Mediator spec)
> just to use Logback.
>
> Personally, I stay away from bytecode weaving in all forms, because I
> really don't want to deal with problems caused by a third party tool
> rewriting the code of other third party libraries, the code of which
> I've never even seen!
>
> Is there some way out of this mess?
>
> I previously did something like this:
> https://www.io7m.com/documents/brutal-felix-logging/
>
> ... but that's only any use if you're embedding a container, and so is
> more or less incompatible with using something like the bnd exporter.
>
> --
> Mark Raynsford | http://www.io7m.com
>
>

-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

Re: Felix Logback with logback >= 1.3.0-alpha4

Posted by Mark Raynsford <li...@io7m.com.INVALID>.
On 2018-10-01T12:42:18 -0400
Raymond Auge <ra...@liferay.com> wrote:

> I'm not sure I can agree with your position on the use of Service Loader
> Mediator.
> 
> We, as an OSGi community, have no choice but to make certain accommodations
> for the development of libraries which are not always going to be used in
> OSGi but DO want to support it in the least intrusive way. Service Loader
> Mediator is exactly that way.
> 
> All, I can suggest is to have a little faith. Aries Spi-Fly is a well used
> and very efficient piece of software that does the absolute minimal amount
> of bytecode manipulation. With the most recent release you can even get
> around ordering issues by using the framework extension (also it's only a
> single bundle with no dependencies) on an R7 framework (both of equinox and
> felix have R7 releases).

Apologies if it came across as overly pessimist. I was just a bit
disappointed by the realization that it's going to become increasingly
necessary to employ bytecode rewriting just to use foundational
Java libraries in OSGi (because JPMS has pushed ServiceLoader into the
foreground, and people are more likely to employ it now that they know
it exists).

Right now I'm using a custom runtime based on Felix, and I use boot
delegation to expose SLF4J to code running inside the container. This
sidesteps the problem, but it's hardly pretty.

-- 
Mark Raynsford | http://www.io7m.com