Package org.ops4j.pax.logging.service.internal.bridges

pax-logging-service (Log4J1) may be extended in two ways: using fragment bundle, so we have access to entire Log4J1 using whiteboard approach, where we register services implementing interfaces from org.ops4j.pax.logging.spi package.

See: Description

Class Summary

Class	Description
AppenderBridgeImpl	Bridge from Log4J to pax-logging.
ErrorHandlerBridgeImpl	Bridge from Log4J to pax-logging.
FilterBridgeImpl	Bridge from Log4J to pax-logging.
LayoutBridgeImpl	Bridge from Log4J to pax-logging.

Package org.ops4j.pax.logging.service.internal.bridges Description

pax-logging-service (Log4J1) may be extended in two ways:

1. using fragment bundle, so we have access to entire Log4J1
2. using whiteboard approach, where we register services implementing interfaces from org.ops4j.pax.logging.spi package.

When using whiteboard approach, we can provide these 4 extensions:

• appenders - by registering PaxAppender service
• filters - by registering PaxFilter service
• layouts - by registering PaxLayout service
• error handlers - by registering PaxErrorHandler service

In configuration (for PID org.ops4j.pax.logging) when encountering appender/filter/layout/errorHandler prefixed with osgi:, a bridge is created and passed to Log4J1. The responsibility of this bridge is to:

• be called by Log4j1
• in case of filter/layout/errorHandler, pass the call to single tracked service or fallback filter/layout/errorHandler
when the service is not found. filter/layout/errorHandler bridges themselves use service trackers
• in case of appender, pass the call to all tracked services without fallback appender(s) when OSGi appenders are not available. Appender bridge doesn't use a service tracker. Instead, appender bridge delegates to PaxAppenderProxy which is service tracker.