Hello

So, for this fragment, do I simply need to make a fragment containing the
> extra log4j information, or do I need to extract the code that is using
> those log4j pieces and put that into a fragment. That seems to be a much
> taller order. Compared to bolting the necessary log4j.core classes onto the
> pax bundle so that those classes are then available to everyone from the
> pax bundles classloader.


First - here's a sample bundle fragment (attached to pax-logging-log4j2)
that adds custom appender:
https://github.com/ops4j/org.ops4j.pax.logging/tree/main/pax-logging-samples/fragment-log4j2

For technical details you have two options (writing without actually
checking, but I did it many times):

   - you create a bundle fragment (with
   <Fragment-Host>org.ops4j.pax.logging.pax-logging-log4j2</Fragment-Host>)
   that simply uses all private package from Log4j2, which are included (but
   not exported) from pax-logging-log4j2. You can implement anything you want,
   including appenders, layouts, ...
   - you create a bundle fragment (again, with
   <Fragment-Host>org.ops4j.pax.logging.pax-logging-log4j2</Fragment-Host>)
   which DOESN'T include any code, but in it's MANIFEST.MF you export the
   packages you need (like "org.apache.logging.log4j.core") and then your
   "caterwaul-connect-core" should be resolved against pax-logging-log4j2 with
   the attached fragment (because effectively, now pax-logging-log4j2 exports
   what you need). AND YOU DON'T install any Log4j2 bundles at all (just
   pax-logging-log4j2)

The 2nd approach look (maybe) more clever and I used it to make Jetty 9
bundles work with servlet-api 4 bundle (because a fragment added additional
exports faking that servlet api 4 exports version 3 of the packages).

I hope this helps.

regards
Grzegorz Grzybek

śr., 13 mar 2024 o 19:00 Will Hartung <[email protected]> napisał(a):

>
>
> On Wed, Mar 13, 2024 at 10:35 AM Jean-Baptiste Onofré <[email protected]>
> wrote:
>
>> Hi Will
>>
>> Did you take a look on
>>
>> https://github.com/apache/karaf/tree/main/examples/karaf-log-appender-example
>> ?
>>
>> Generally speaking, the org.apache.logging* packages should be
>> imported in your bundle. The fragment would extend an existing bundle
>> classloader with your classes.
>>
>> Maybe if you share a test case bundle, I can show you how to do this.
>>
>
> I'm trying to port an existing code base, originally organized as some
> Maven modules. I'm treating the individual jars independently,  and making
> them bundles individually. One of the bundles has a Log4j appender class of
> its own, this is in contrast to the example you posted which seems to be a
> specific pax appender.
>
> There's also some other code. It looks like this:
>
>     @Override
>     public IELogLevel toIELogLevel(Object rawLogEvent) {
>         String logEventClsName = rawLogEvent.getClass().getName();
>         switch(logEventClsName) {
>             case "org.apache.log4j.spi.LoggingEvent":
>                 LoggingEvent loggingEvent = (LoggingEvent)rawLogEvent;
>                 return
> IELogLevel.valueOf(loggingEvent.getLevel().toString());
>             case "org.apache.logging.log4j.core.LogEvent":
>             case "org.apache.logging.log4j.core.impl.Log4jLogEvent":
>                 LogEvent logEvent = (LogEvent)rawLogEvent;
>                 return
> IELogLevel.valueOf(logEvent.getLevel().getStandardLevel().toString());
>             default:
>                 System.out.printf("Unrecognized log event class flavor
> '%s'. Returning INFO%n", logEventClsName);
>                 return IELogLevel.INFO;
>         }
>     }
>
> This is not my code, as in I'm not intimately familiar with it at this
> level, I'm trying to just get it all bundled up to run in an OSGI
> container. I honestly don't know what calls this at the moment. Then come
> back to make some passes with declarative services and things like that.
> But out the gate, just trying to get the thing firing on a few cylinders.
>
> So, I'm not ready to try and break code out if I don't have to, if I can
> get by with classpath/bundlepath shenanigans to get the baseline running.
>
> Can a fragment solve this? It seems to me a fragment extends the
> classloader of another bundle. It inserts itself into another bundles
> internal environment. In that, should it be trying to export the log4j
> classes from the pax bundle (which i don't even know if it has these
> classes internally, I don't know how pax logging works)?
>
> Just not sure what the role a fragment might fill or how that would work
> at this juncture.
>
> Thanks again.
>
> Regards,
>
> Will Hartung
>
>
>
>

Reply via email to