No implementations available for PaxAppender [PAXLOGGING-72]

[ops4j-issues]

M created PAXLOGGING-72

Currently it is not possible to use own appender based on log4j using existing PaxLoggingConfigurator. It is really strange because PaxLoggingConfigurator is based on log4j appenders.
There can be used only PaxAppender implementation, but none is available.

There are two solutions to solve the problem. Both are bad.

• create own appender based on log4j appender and attach it via Fragment-Host mechanism to Pax Logging Service bundle – bad solution, because current PaxLoggingConfigurator do not support error handlers etc (I've already created PAXLOGGING-71 for it)
• write PaxAppender implementation which aggregates any log4 appender - bad, because it requires an additional log4j bundle in the application (Pax Logging exports only two log4j packages without most of log4j code, especially without appenders), what is more it is a performance killer, because PaxAppender implementation wraps some appender based on log4 appender, and PAX creates own wrapper to return log4j appender from PaxAppender...

There are two complementary solution:

• PAXLOGGING-71
• PaxLoggingConfigurator or its AppenderTracker should track not only PaxAppender but original log4j Appender. What is more all log4j packages should be exported.

---

Affects: 1.4 Votes: 0, Watches: 1

---

Referenced issues

relates to:

• 162 - Support for filters, error handlers and nested appenders [PAXLOGGING-76]

[ops4j-issues]

NiclasH commented

I am not sure what this issue is really about. It talks about problems and solutions to an somewhat undefined requirement. Please clarify.

"requires an additional bundle" --> What is wrong with that? It was a goal from the start to make Pax Logging a showcase of OSGi modularity, where one would load what one needs. So, initially I wanted to achieve that each appender was its own bundle with its own configuration. That was kind of sidetracked, mostly due to time constraints. It was definitely a mistake to expose the Log4J configuration to the users, as we are now not able to change the underlying implementation to something more OSGi-friendly.

Secondly, it is not possible to "all log4j packages should be exported". I assume you mean the Pax Logging Service. That will interfere with both the Pax Logging API's need to export the Log4J API, AND it will fail to trap application code that is incompatible with Pax Logging's Log4J support. It is unwise to let application code meddle with Log4J since it may break everything and you would be no wiser of "why".

[ops4j-issues]

M commented

The problem is "it is not possible to use own appender based on log4j using existing PaxLoggingConfigurator."

For example I have own log4j appender implementation which extends some log4j appender implementation.
I have it already. It works perfectly in non-OSGI environment.

I'm unable to use it via PaxLoggingConfigurator, because PaxLoggingConfigurator won't see it.
PaxLoggingConfigurator sees only log4j appenders in its log4j embbeded jar.
The only way to use own appender is to provide PaxAppender as a OSGI service.

Because there is no PaxAppender implementation, i'm forced to create PaxAppender wrapper which transforms PaxLoggingEvent into log4j LoggingEvent and pass it to my own log4j appender. But I'm unable to provide own log4j appender, because PAX Logging doesn;t export all log4j code.

To do so
"it requires an additional log4j bundle in the application" - because log4j in already embedded in the PAX Logging Service.
PaxLogging API exports some log4j packages as well. So we have at least three log4j in the system. Two for PAX and one for my new appender.

"all log4j packages should be exported" - because at the moment log4j logger can be used for logging, but it is impossible to provide own appenders.

So in my opinion :
PAX Logging API should contain and export all log4j packages.
PAX Logging Service should not embed log4j jar, but should import necessary log4j packages.(from PAX Logging API bundle)
PAX Logging Service and its PaxLoggingConfigurator should be able to use not only PaxAppenders provided by OSGI service, but log4j Appenders as well. Creating AppenderBridgeImpl is not necessary.

I know that the subject is not straightforward.
The issue with PAX Logging is that its configuration is based on log4j, but it is impossible to use all log4j capabilities.

[ops4j-issues]

NiclasH commented

"So in my opinion" --> Not possible.
1. The Log4j packages in Pax Logging API are NOT original code and augmented to fit into the OSGi environment.

2. I want to be able to upgrade Pax Logging Service, esp the Log4j implementation (perhaps not so relevant anymore) WITHOUT stopping the entire application.

3. I strongly want to avoid DynamicImport, so it won't be possible to "just use" any class that implements Log4j Appender.

"it is impossible to use all log4j capabilities" --> Yes, and it is both by design and by necessity. Sorry.

Perhaps if you explain what you want your own Appender to do, we just create one for Pax Logging, and if there is something substantially missing in the PaxAppender approach, we add that. But since you so far is very, very vague on what you want to do, there is little I can help with.

[ops4j-issues]

NiclasH commented

And another thing, Yes I have contemplated many times to provide more than one Pax Logging Service implementation. LogBack, JDK Logging and even in-house one have been considered, but no real passion to do it...

[ops4j-issues]

M commented

My appender is org.apache.log4j.DailyRollingFileAppender with own layout and own error handler. I configure this appender in Spring DM:

    <bean id="myAppender" class="org.apache.log4j.DailyRollingFileAppender" init-method="activateOptions">
        <property name="name" value="MyAppender"/>
        <property name="append" value="true"/>
        <property name="datePattern" value="'.'yyyy-MM-dd-HH"/>
        <property name="file" value="${karaf.base}/data/log/someLog.log"/>
        <property name="threshold">
            <util:constant static-field="org.apache.log4j.Level.DEBUG"/>
        </property>
        <property name="layout">
            <bean class="com.xxxxx.log4j.layout.SophisticatedLayout">
                <property name="conversionPattern" value="..."/>
            </bean>
        </property>
        <property name="errorHandler">
            <bean class="com......SomeErrorHandler" init-method="activateOptions">
                <property name="appender" ref="myAppender"/><!-- must be this appender -->
                <property name="backupAppender" ref="someOtherAppender"/>
                <property name="a" value="c"/>
                <property name="b" value="d"/>
            </bean>
        </property>
    </bean>

    <bean id="myPaxAppender" class="com.......PaxLog4jAppenderWrapper">
        <property name="log4jAppender" ref="myAppender"/>
    </bean> 

    <osgi:service ref="myPaxAppender" interface="org.ops4j.pax.logging.spi.PaxAppender">
        <osgi:service-properties>
            <entry>
                <key>
                    <util:constant static-field="org.ops4j.pax.logging.PaxLoggingService.APPENDER_NAME_PROPERTY"/>
                </key>
                <value>MyAppender</value>
            </entry>
        </osgi:service-properties>
    </osgi:service>

and $

{karaf.base}

/etc/org.ops4j.pax.logging.cfg contains like:

log4j.logger.com.myCompany=INFO, osgi:MyAppender

This solution needs additional log4j bundle in the application, but it works.

And answer for your comments:
>1. The Log4j packages in Pax Logging API are NOT original code and augmented to fit into the OSGi environment.
What kind of changes? Could you provide some link to the docs about them, or point the classes which are changed?

>3. I strongly want to avoid DynamicImport, so it won't be possible to "just use" any class that implements Log4j Appender.
Me neither. But the appender would be provided via OSGI service as it is PaxAppender implementation, so PAX doesn't have to DynamicImport?

>"it is impossible to use all log4j capabilities" --> Yes, and it is both by design and by necessity. Sorry.
Very strange especially PAX Logging configuration is based on log4j.

>Perhaps if you explain what you want your own Appender to do, we just create one for Pax Logging,
Provide all log4j appenders as PaxAppenders and export them that other bundles can extend them.

>but no real passion to do it...
The whole OSGI is not easy as it is supposed to be.

[ops4j-issues]

Guillaume Nodet commented

I think with PAXLOGGING-76 being fixed, such a workaround is not really needed anymore.

[ops4j-issues]

M commented

PAXLOGGING-76 has fixed the problem partially.
To use own log4j appenders, filters or error handlers it still requires the Fragment-Host mechanism.

However it is a big step and adding a wrapper is not necessary now.

[ops4j-issues]

Niclas Hedhman commented

This issue is too vague to be useful. Reporter claim that the identifiable part has been addressed, and the rest seems to be outside the scope of Pax Logging.