Re: Karaf log4j conflict

[Will Hartung]

On Wed, Mar 13, 2024 at 11:07 PM Grzegorz Grzybek 
wrote:

> I hope this helps.
>
> regards
> Grzegorz Grzybek
>
> It looks helpful, I'll take a stab at it next week and follow up. Thank
you.

Regards,

Will Hartung

RE: Karaf log4j conflict

[Siano, Stephan via user]

Hi,

Maybe I add some technical explanation which might clear things up a little.

Pax-Logging essentially consists of two parts, a frontend that implements 
different logging APIs (slf4j, OSGi logging service, log4j2, apache commons 
logging…) and a backend, which is doing the actual logging and which is 
configured with the karaf logging configuration. There are two backends,  one 
using log4j2 (the default) and one using logback, which means that one of these 
log frameworks is actually there in the backend, but the classes are usually 
hidden (and the code that is accessing them will depend on the backend).

There are actually three different kinds of code that may interact with loggers:

  1.  Code that is using one of the logging APIs to write logs.
  2.  Code that is extending the logger e.g. by a custom extender to write 
specific log formats that are not supported out of the box
  3.  Code that does both and may also configure loggers but also extends 
loggers and writes logs

Code of the first type is simple, It should work out of the box.

Code of the second type should go into a fragment of the pax-logging backend. 
The fragment is an extension of the actual backend bundle. It has full access 
to all backend classes (e.g. log4j2) classes in the fragment are also 
accessible from the backend (this is important if you have your own extender 
and want to configure it in the log configuration of the Karaf container).

Code of the 3rd type is problematic, and you might have to refactor it. The 
fragment that is exporting the internal backend classes as Grzegorz mentioned 
might help you in some cases, but this means that your classes can access the 
log4j classes, but log4j cannot access your classes (which means that if your 
code contains an appender, the appender would theoretically work, but log4j 
cannot instantiate it.

If I were you, I would remove the log4j specific code of the second and third 
type for now (of course you should keep the code that is writing logs in the 
first place). This means that the logs you are writing may not have the format 
or the log levels you are intending but this should not impact the general 
functionality.
Once the code is running you can consider log configuration and custom 
appenders and add them to a fragment (and the container log configuration).

Best regards
Stephan

From: Grzegorz Grzybek 
Sent: Thursday, 14 March 2024 07:07
To: user@karaf.apache.org
Subject: Re: Karaf log4j conflict

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 
org.ops4j.pax.logging.pax-logging-log4j2) 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 
org.ops4j.pax.logging.pax-logging-log4j2) 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 
mailto:willhart...@gmail.com>> napisał(a):


On Wed, Mar 13, 2024 at 10:35 AM Jean-Baptiste Onofré 
mailto:j...@nanthrax.net>> 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 

Re: Karaf log4j conflict

[Grzegorz Grzybek]

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
   org.ops4j.pax.logging.pax-logging-log4j2)
   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
   org.ops4j.pax.logging.pax-logging-log4j2)
   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  napisał(a):

>
>
> On Wed, Mar 13, 2024 at 10:35 AM Jean-Baptiste Onofré 
> 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
>
>
>
>

Re: Karaf log4j conflict

[Will Hartung]

On Wed, Mar 13, 2024 at 10:35 AM Jean-Baptiste Onofré 
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

Re: Karaf log4j conflict

[Jean-Baptiste Onofré]

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.

Regards
JB

On Wed, Mar 13, 2024 at 6:28 PM Will Hartung  wrote:
>
>
>
> On Mon, Mar 11, 2024 at 11:33 PM Grzegorz Grzybek  
> wrote:
>>
>> Hello
>>
>> Pax Logging (where pax-logging-api contains and exports Logging APIs, while 
>> pax-logging-log4j2 is the Log4j2-based implementation) has enormous amount 
>> of effort put into integration of very different logging packages and it is 
>> used by Apache Karaf among others.
>>
>> The team developed Pax Logging for many years trying to maintain old APIs 
>> and include new ones. Among others, there's one consequence of this - either 
>> you use Pax Logging and accept some (workarounds possible) limitation or you 
>> craft your own set of bundles approaching what Pax Logging does anyway.
>>
>> Your issue is simple - your "caterwaul-connect-core" bundle imports 
>> "org.apache.logging.log4j.core" which is simply NOT exported by 
>> pax-logging-log4j2. This (at first glance) means you NEED actual Log4j2 
>> bundles installed.
>>
>> However - are you sure your "caterwaul-connect-core" bundle really needs 
>> this package? is it implementing custom appenders/layouts/plugins? If so, 
>> it's better (and Pax Logging contains relevant examples) to create a 
>> fragment bundle attached to pax-logging-log4j2 bundle.
>>
> Hi, thanks for getting back.
>
> Yes, it seems that the code is doing a couple of things. One is creating its 
> own appender, and another it seems to be looking at different kinds of events 
> that contain raw logging information, so it's using some of the classes to 
> extract information from those.
>
> 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.
>
> Thanks!
>
> Regards,
>
> Will Hartung
>

Re: Karaf log4j conflict

[Will Hartung]

On Mon, Mar 11, 2024 at 11:33 PM Grzegorz Grzybek 
wrote:

> Hello
>
> Pax Logging (where pax-logging-api contains and exports Logging APIs,
> while pax-logging-log4j2 is the Log4j2-based implementation) has enormous
> amount of effort put into integration of very different logging packages
> and it is used by Apache Karaf among others.
>
> The team developed Pax Logging for many years trying to maintain old APIs
> and include new ones. Among others, there's one consequence of this -
> either you use Pax Logging and accept some (workarounds possible)
> limitation or you craft your own set of bundles approaching what Pax
> Logging does anyway.
>
> Your issue is simple - your "caterwaul-connect-core" bundle imports
> "org.apache.logging.log4j.core" which is simply NOT exported by
> pax-logging-log4j2. This (at first glance) means you NEED actual Log4j2
> bundles installed.
>
> However - are you sure your "caterwaul-connect-core" bundle really needs
> this package? is it implementing custom appenders/layouts/plugins? If so,
> it's better (and Pax Logging contains relevant examples) to create a
> fragment bundle attached to pax-logging-log4j2 bundle.
>
> Hi, thanks for getting back.

Yes, it seems that the code is doing a couple of things. One is creating
its own appender, and another it seems to be looking at different kinds of
events that contain raw logging information, so it's using some of the
classes to extract information from those.

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.

Thanks!

Regards,

Will Hartung

Re: Karaf log4j conflict

[Grzegorz Grzybek]

Hello

Pax Logging (where pax-logging-api contains and exports Logging APIs, while
pax-logging-log4j2 is the Log4j2-based implementation) has enormous amount
of effort put into integration of very different logging packages and it is
used by Apache Karaf among others.

The team developed Pax Logging for many years trying to maintain old APIs
and include new ones. Among others, there's one consequence of this -
either you use Pax Logging and accept some (workarounds possible)
limitation or you craft your own set of bundles approaching what Pax
Logging does anyway.

Your issue is simple - your "caterwaul-connect-core" bundle imports
"org.apache.logging.log4j.core" which is simply NOT exported by
pax-logging-log4j2. This (at first glance) means you NEED actual Log4j2
bundles installed.

However - are you sure your "caterwaul-connect-core" bundle really needs
this package? is it implementing custom appenders/layouts/plugins? If so,
it's better (and Pax Logging contains relevant examples) to create a
fragment bundle attached to pax-logging-log4j2 bundle.

regards
Grzegorz Grzybek

pon., 11 mar 2024 o 21:51 Will Hartung  napisał(a):

> I've been trying to get our legacy application running in an OSGI runtime,
> and have been trying with Karaf.
>
> After much pushing modules around, I was getting this error about Log4j:
>
> Error executing command: Error executing command on bundles:
> Error starting bundle 138: Unable to resolve caterwaul-connect-core
> [138](R 138.1): missing requirement [caterwaul-connect-core [138](R 138.1)]
> osgi.wiring.package; (osgi.wiring.package=org.apache.logging.log4j.core)
> Unresolved requirements: [[caterwaul-connect-core [138](R 138.1)]
> osgi.wiring.package; (osgi.wiring.package=org.apache.logging.log4j.core)]
>
> So, I added in log4j-api-2.20.0.jar, and log4j-core-2.20.0.jar.
>
> These loaded, resolve, and start fine, but now when I try to start my
> bundle I get:
>
> Error executing command: Error executing command on bundles:
> Error starting bundle 138: Uses constraint violation. Unable to resolve
> resource caterwaul-connect-core [caterwaul-connect-core [138](R 138.1)]
> because it is exposed to package 'org.apache.logging.log4j' from resources
> org.ops4j.pax.logging.pax-logging-api
> [org.ops4j.pax.logging.pax-logging-api [5](R 5.0)] and
> org.apache.logging.log4j.api [org.apache.logging.log4j.api [215](R 215.0)]
> via two dependency chains.
>
> Chain 1:
>   caterwaul-connect-core [caterwaul-connect-core [138](R 138.1)]
> import: (osgi.wiring.package=org.apache.logging.log4j)
>  |
> export: osgi.wiring.package: org.apache.logging.log4j
>   org.ops4j.pax.logging.pax-logging-api
> [org.ops4j.pax.logging.pax-logging-api [5](R 5.0)]
>
> Chain 2:
>   caterwaul-connect-core [caterwaul-connect-core [138](R 138.1)]
> import: (osgi.wiring.package=org.apache.logging.log4j.core)
>  |
> export: osgi.wiring.package=org.apache.logging.log4j.core;
> uses:=org.apache.logging.log4j
>   org.apache.logging.log4j.core [org.apache.logging.log4j.core [214](R
> 214.0)]
> import:
> (&(osgi.wiring.package=org.apache.logging.log4j)(version>=2.20.0)(!(version>=3.0.0)))
>  |
> export: osgi.wiring.package: org.apache.logging.log4j
>   org.apache.logging.log4j.api [org.apache.logging.log4j.api [215](R
> 215.0)] Unresolved requirements: [[caterwaul-connect-core [138](R 138.1)]
> osgi.wiring.package; (osgi.wiring.package=org.apache.logging.log4j.core)]
>
> It was my understanding that Karaf bundled logging. In fact, that was a
> motivator to trying in. My adventures with Felix were derailed with trying
> to get SLF4J to start and wire properly (even when using the pax logging
> bundle).
>
> But, now, when I include the log4j bundles, it complains that there's a
> conflict from the two sources for log4j. If I go and uninstall the log4j
> core bundle, then I no longer get the conflict about too many log4js, but
> the complaint that it can't find it at all.
>
> How can I reconcile this impasse?
>
> Thanks!
>
> Regards,
>
> Will Hartung
>
>

Karaf log4j conflict

[Will Hartung]

I've been trying to get our legacy application running in an OSGI runtime,
and have been trying with Karaf.

After much pushing modules around, I was getting this error about Log4j:

Error executing command: Error executing command on bundles:
Error starting bundle 138: Unable to resolve caterwaul-connect-core [138](R
138.1): missing requirement [caterwaul-connect-core [138](R 138.1)]
osgi.wiring.package; (osgi.wiring.package=org.apache.logging.log4j.core)
Unresolved requirements: [[caterwaul-connect-core [138](R 138.1)]
osgi.wiring.package; (osgi.wiring.package=org.apache.logging.log4j.core)]

So, I added in log4j-api-2.20.0.jar, and log4j-core-2.20.0.jar.

These loaded, resolve, and start fine, but now when I try to start my
bundle I get:

Error executing command: Error executing command on bundles:
Error starting bundle 138: Uses constraint violation. Unable to resolve
resource caterwaul-connect-core [caterwaul-connect-core [138](R 138.1)]
because it is exposed to package 'org.apache.logging.log4j' from resources
org.ops4j.pax.logging.pax-logging-api
[org.ops4j.pax.logging.pax-logging-api [5](R 5.0)] and
org.apache.logging.log4j.api [org.apache.logging.log4j.api [215](R 215.0)]
via two dependency chains.

Chain 1:
  caterwaul-connect-core [caterwaul-connect-core [138](R 138.1)]
import: (osgi.wiring.package=org.apache.logging.log4j)
 |
export: osgi.wiring.package: org.apache.logging.log4j
  org.ops4j.pax.logging.pax-logging-api
[org.ops4j.pax.logging.pax-logging-api [5](R 5.0)]

Chain 2:
  caterwaul-connect-core [caterwaul-connect-core [138](R 138.1)]
import: (osgi.wiring.package=org.apache.logging.log4j.core)
 |
export: osgi.wiring.package=org.apache.logging.log4j.core;
uses:=org.apache.logging.log4j
  org.apache.logging.log4j.core [org.apache.logging.log4j.core [214](R
214.0)]
import:
(&(osgi.wiring.package=org.apache.logging.log4j)(version>=2.20.0)(!(version>=3.0.0)))
 |
export: osgi.wiring.package: org.apache.logging.log4j
  org.apache.logging.log4j.api [org.apache.logging.log4j.api [215](R
215.0)] Unresolved requirements: [[caterwaul-connect-core [138](R 138.1)]
osgi.wiring.package; (osgi.wiring.package=org.apache.logging.log4j.core)]

It was my understanding that Karaf bundled logging. In fact, that was a
motivator to trying in. My adventures with Felix were derailed with trying
to get SLF4J to start and wire properly (even when using the pax logging
bundle).

But, now, when I include the log4j bundles, it complains that there's a
conflict from the two sources for log4j. If I go and uninstall the log4j
core bundle, then I no longer get the conflict about too many log4js, but
the complaint that it can't find it at all.

How can I reconcile this impasse?

Thanks!

Regards,

Will Hartung

Re: Hotfix for Log4j Vulnerability

[Raggy Fab]

Correct - by hotfix I mean updating the log4j version without upgrading to
karaf 4.3.4. Restarting Karaf is not an issue.
Thanks for the hint regarding bundle:update.
I prefer removing the vulnerable log4j from the classpath (which this
procedure achieves)

Am Mo., 13. Dez. 2021 um 14:02 Uhr schrieb Jean-Baptiste Onofré <
j...@nanthrax.net>:

> By hotfix, you mean patching while running ?
>
> Maybe you can do a bundle:update instead of bundle:install, but
> basically correct.
>
> My point is that you don't have to upgrade if you use the workaround
> (that can be added at runtime, restart pax-logging bundle).
>
> Regards
> JB
>
> On 13/12/2021 14:00, Raggy Fab wrote:
> > Hi JB,
> >
> > OK - Let me summarize.
> >
> > if I want to do a hotfix, I need to swap pax logging (run level fixed my
> > previous problem):
> > bundle:install -l 8 mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11
> > bundle:install -l 8 mvn:org.ops4j.pax.logging/pax-logging-api/2.0.11
> > bundle:uninstall 6
> > bundle:uninstall 7
> >
> > Then replace old pax-logging-api and pax-logging-log4j2 entries in
> > startup.properties:
> > mvn\:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11 = 8
> > mvn\:org.ops4j.pax.logging/pax-logging-api/2.0.11 = 8
> >
> > Correct?
> > This should be a fairly safe upgrade, even for older Karaf versions, do
> > you agree?
> >
> > Kind Regards,
> > Raggy
> >
> > Am Mo., 13. Dez. 2021 um 13:44 Uhr schrieb Jean-Baptiste Onofré
> > mailto:j...@nanthrax.net>>:
> >
> > Hi Raggy,
> >
> > without upgrading, you can use a workaround.
> >
> > log4j2.formatMsgNoLookups=true in etc/system.properties should do
> > the trick.
> >
> > If you want to upgrade, you have to change in etc/startup.properties
> > (and populate system repo).
> >
> > Regards
> > JB
> >
> > On 13/12/2021 13:42, Raggy Fab wrote:
> >  > Hello,
> >  >
> >  > I am aware that the new karaf version 4.3.4 will fix the Log4j
> >  > Vulnerability (CVE-2021-44228).
> >  >
> >  > However, I can't upgrade karaf in my project. Is there a hotfix
> > option?
> >  > (Ideally only touching log4j)
> >  >
> >  > I tried to swap out Pax Logging:
> >  > bundle:install mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11
> >  > bundle:install mvn:org.ops4j.pax.logging/pax-logging-api/2.0.11
> >  > bundle:uninstall 6
> >  > bundle:uninstall 7
> >  >
> >  > Log files are written, but I get class path issues like (Bundles
> no
> >  > longer starting up):
> >  > ClassNotFoundException: org.apache.commons.logging.LogFactory
> >  >
> >  > kind regards,
> >  > Raggy
> >
>

Re: Hotfix for Log4j Vulnerability

[Jean-Baptiste Onofré]

By hotfix, you mean patching while running ?

Maybe you can do a bundle:update instead of bundle:install, but 
basically correct.


My point is that you don't have to upgrade if you use the workaround 
(that can be added at runtime, restart pax-logging bundle).


Regards
JB

On 13/12/2021 14:00, Raggy Fab wrote:

Hi JB,

OK - Let me summarize.

if I want to do a hotfix, I need to swap pax logging (run level fixed my 
previous problem):

bundle:install -l 8 mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11
bundle:install -l 8 mvn:org.ops4j.pax.logging/pax-logging-api/2.0.11
bundle:uninstall 6
bundle:uninstall 7

Then replace old pax-logging-api and pax-logging-log4j2 entries in 
startup.properties:

mvn\:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11 = 8
mvn\:org.ops4j.pax.logging/pax-logging-api/2.0.11 = 8

Correct?
This should be a fairly safe upgrade, even for older Karaf versions, do 
you agree?


Kind Regards,
Raggy

Am Mo., 13. Dez. 2021 um 13:44 Uhr schrieb Jean-Baptiste Onofré 
mailto:j...@nanthrax.net>>:


Hi Raggy,

without upgrading, you can use a workaround.

log4j2.formatMsgNoLookups=true in etc/system.properties should do
the trick.

If you want to upgrade, you have to change in etc/startup.properties
(and populate system repo).

Regards
JB

On 13/12/2021 13:42, Raggy Fab wrote:
 > Hello,
 >
 > I am aware that the new karaf version 4.3.4 will fix the Log4j
 > Vulnerability (CVE-2021-44228).
 >
 > However, I can't upgrade karaf in my project. Is there a hotfix
option?
 > (Ideally only touching log4j)
 >
 > I tried to swap out Pax Logging:
 > bundle:install mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11
 > bundle:install mvn:org.ops4j.pax.logging/pax-logging-api/2.0.11
 > bundle:uninstall 6
 > bundle:uninstall 7
 >
 > Log files are written, but I get class path issues like (Bundles no
 > longer starting up):
 > ClassNotFoundException: org.apache.commons.logging.LogFactory
 >
 > kind regards,
 > Raggy

Re: Hotfix for Log4j Vulnerability

[Raggy Fab]

Hi JB,

OK - Let me summarize.

if I want to do a hotfix, I need to swap pax logging (run level fixed my
previous problem):
bundle:install -l 8 mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11
bundle:install -l 8 mvn:org.ops4j.pax.logging/pax-logging-api/2.0.11
bundle:uninstall 6
bundle:uninstall 7

Then replace old pax-logging-api and pax-logging-log4j2 entries in
startup.properties:
mvn\:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11 = 8
mvn\:org.ops4j.pax.logging/pax-logging-api/2.0.11 = 8

Correct?
This should be a fairly safe upgrade, even for older Karaf versions, do you
agree?

Kind Regards,
Raggy

Am Mo., 13. Dez. 2021 um 13:44 Uhr schrieb Jean-Baptiste Onofré <
j...@nanthrax.net>:

> Hi Raggy,
>
> without upgrading, you can use a workaround.
>
> log4j2.formatMsgNoLookups=true in etc/system.properties should do the
> trick.
>
> If you want to upgrade, you have to change in etc/startup.properties
> (and populate system repo).
>
> Regards
> JB
>
> On 13/12/2021 13:42, Raggy Fab wrote:
> > Hello,
> >
> > I am aware that the new karaf version 4.3.4 will fix the Log4j
> > Vulnerability (CVE-2021-44228).
> >
> > However, I can't upgrade karaf in my project. Is there a hotfix option?
> > (Ideally only touching log4j)
> >
> > I tried to swap out Pax Logging:
> > bundle:install mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11
> > bundle:install mvn:org.ops4j.pax.logging/pax-logging-api/2.0.11
> > bundle:uninstall 6
> > bundle:uninstall 7
> >
> > Log files are written, but I get class path issues like (Bundles no
> > longer starting up):
> > ClassNotFoundException: org.apache.commons.logging.LogFactory
> >
> > kind regards,
> > Raggy
>

Re: Hotfix for Log4j Vulnerability

[Jean-Baptiste Onofré]

Hi Raggy,

without upgrading, you can use a workaround.

log4j2.formatMsgNoLookups=true in etc/system.properties should do the trick.

If you want to upgrade, you have to change in etc/startup.properties 
(and populate system repo).


Regards
JB

On 13/12/2021 13:42, Raggy Fab wrote:

Hello,

I am aware that the new karaf version 4.3.4 will fix the Log4j 
Vulnerability (CVE-2021-44228).


However, I can't upgrade karaf in my project. Is there a hotfix option? 
(Ideally only touching log4j)


I tried to swap out Pax Logging:
bundle:install mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11
bundle:install mvn:org.ops4j.pax.logging/pax-logging-api/2.0.11
bundle:uninstall 6
bundle:uninstall 7

Log files are written, but I get class path issues like (Bundles no 
longer starting up):

ClassNotFoundException: org.apache.commons.logging.LogFactory

kind regards,
Raggy

Hotfix for Log4j Vulnerability

[Raggy Fab]

Hello,

I am aware that the new karaf version 4.3.4 will fix the Log4j
Vulnerability (CVE-2021-44228).

However, I can't upgrade karaf in my project. Is there a hotfix option?
(Ideally only touching log4j)

I tried to swap out Pax Logging:
bundle:install mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11
bundle:install mvn:org.ops4j.pax.logging/pax-logging-api/2.0.11
bundle:uninstall 6
bundle:uninstall 7

Log files are written, but I get class path issues like (Bundles no longer
starting up):
ClassNotFoundException: org.apache.commons.logging.LogFactory

kind regards,
Raggy

Re: Karaf 3.0.x "Apache Log4j Remote Code Execution Vulnerability" mitigation?

[JB Onofré]

Hi Paul

Only log4j 2.x is only impacted, Karaf 3.0/pax logging 1.8 uses log4j 1.x so no 
problem. 

Regards 
JB

> Le 12 déc. 2021 à 19:18, Paul Spencer  a écrit :
> 
> For users of Karaf 3.0.x that uses Pax Logging version 1.8.x, what is the 
> recommended mitigation for "Apache Log4j Remote Code Execution 
> Vulnerability", CVE-2021-44228?
> 
> Paul Spencer
> 

Karaf 3.0.x "Apache Log4j Remote Code Execution Vulnerability" mitigation?

[Paul Spencer]

For users of Karaf 3.0.x that uses Pax Logging version 1.8.x, what is the 
recommended mitigation for "Apache Log4j Remote Code Execution Vulnerability", 
CVE-2021-44228?

Paul Spencer

Re: Karaf 4.2.x "Apache Log4j Remote Code Execution Vulnerability" mitigation?

[Jean-Baptiste Onofre]

I already replied to Oleg:

log4j2.formatMsgNoLookups=true

In system.properties

Regards
JB

> Le 12 déc. 2021 à 19:05, Paul Spencer  a écrit :
> 
> For users of Karaf 4.2.x, what is the recommended mitigation for "Apache 
> Log4j Remote Code Execution Vulnerability", CVE-2021-44228?
> 
> Paul Spencer
> 

Karaf 4.2.x "Apache Log4j Remote Code Execution Vulnerability" mitigation?

[Paul Spencer]

For users of Karaf 4.2.x, what is the recommended mitigation for "Apache Log4j 
Remote Code Execution Vulnerability", CVE-2021-44228?

Paul Spencer

Re: Karaf 4.3.x "Apache Log4j Remote Code Execution Vulnerability" mitigation?

[Oleg Cohen]

Thank  you!

On Dec 12, 2021, at 10:13 AM, Jean-Baptiste Onofre  wrote:

log4j2.formatMsgNoLookups=true in etc/system.properties should do the trick.

Regards
JB

Le 12 déc. 2021 à 18:10, Oleg Cohen  a écrit :

Hi JB,

Thank you for the info.

Do you have an example of how this can be dome in system.properties?

Best,
Oleg

On Dec 12, 2021, at 10:08 AM, JB Onofré  wrote:

You can use system.properties to set the msg format on existing version.

Else Karaf 4.3.4 will include fix by default.

Le 12 déc. 2021 à 17:54, Paul Spencer  a écrit :

For users of Karaf 4.3.x, what is the recommended mitigation for "Apache
Log4j Remote Code Execution Vulnerability", CVE-2021-44228?

Paul Spencer

Re: Karaf 4.3.x "Apache Log4j Remote Code Execution Vulnerability" mitigation?

[Jean-Baptiste Onofre]

log4j2.formatMsgNoLookups=true in etc/system.properties should do the trick.

Regards
JB

> Le 12 déc. 2021 à 18:10, Oleg Cohen  a écrit :
> 
> Hi JB,
> 
> Thank you for the info.
> 
> Do you have an example of how this can be dome in system.properties?
> 
> Best,
> Oleg
> 
>> On Dec 12, 2021, at 10:08 AM, JB Onofré  wrote:
>> 
>> You can use system.properties to set the msg format on existing version. 
>> 
>> Else Karaf 4.3.4 will include fix by default. 
>> 
>>> Le 12 déc. 2021 à 17:54, Paul Spencer  a écrit :
>>> 
>>> For users of Karaf 4.3.x, what is the recommended mitigation for "Apache 
>>> Log4j Remote Code Execution Vulnerability", CVE-2021-44228?
>>> 
>>> Paul Spencer
>>> 
>> 
> 

Re: Karaf 4.3.x "Apache Log4j Remote Code Execution Vulnerability" mitigation?

[Oleg Cohen]

Hi JB,

Thank you for the info.

Do you have an example of how this can be dome in system.properties?

Best,
Oleg

> On Dec 12, 2021, at 10:08 AM, JB Onofré  wrote:
> 
> You can use system.properties to set the msg format on existing version. 
> 
> Else Karaf 4.3.4 will include fix by default. 
> 
>> Le 12 déc. 2021 à 17:54, Paul Spencer  a écrit :
>> 
>> For users of Karaf 4.3.x, what is the recommended mitigation for "Apache 
>> Log4j Remote Code Execution Vulnerability", CVE-2021-44228?
>> 
>> Paul Spencer
>> 
> 

Re: Karaf 4.3.x "Apache Log4j Remote Code Execution Vulnerability" mitigation?

[JB Onofré]

You can use system.properties to set the msg format on existing version. 

Else Karaf 4.3.4 will include fix by default. 

> Le 12 déc. 2021 à 17:54, Paul Spencer  a écrit :
> 
> For users of Karaf 4.3.x, what is the recommended mitigation for "Apache 
> Log4j Remote Code Execution Vulnerability", CVE-2021-44228?
> 
> Paul Spencer
> 

Karaf 4.3.x "Apache Log4j Remote Code Execution Vulnerability" mitigation?

[Paul Spencer]

For users of Karaf 4.3.x, what is the recommended mitigation for "Apache Log4j 
Remote Code Execution Vulnerability", CVE-2021-44228?

Paul Spencer

Re: log4j warning at startup

[Jean-Baptiste Onofre]

Thanks for the update. Good to know for windows users.

Regards
JB

> Le 17 févr. 2021 à 16:31, Jörg Jansen  a 
> écrit :
> 
> Hi JB, 
> 
> Just found a solution. 
> Setting system property -Dsun.stdout.encoding=UTF-8 solved the issue. 
> 
> Regards,
> Joerg
> 
> -Original Message-
> From: Jörg Jansen 
> Sent: Mittwoch, 17. Februar 2021 15:03
> To: user 
> Subject: RE: log4j warning at startup
> 
> Hi JB, 
> 
> yes, I tried with the original downloaded  (and unmodified!) assembly. 
> The strange thing is, that it seems only to be present on the Windows server 
> edition. 
> On my local workstation (win 10) it's also working fine. 
> 
> Comparing the classpath and locale settings show no difference.
> 
> Regards,
> Joerg
> 
> -Original Message-
> From: Jean-Baptiste Onofre 
> Sent: Mittwoch, 17. Februar 2021 14:22
> To: user 
> Subject: Re: log4j warning at startup
> 
> Hi Joerg,
> 
> I didn’t see such ERROR message (ok, I’m not using Windows ;)).
> 
> Are you using the default etc/org.ops4j.pax.logging.cfg ?
> 
> Regards
> JB
> 
>> Le 17 févr. 2021 à 12:19, Jörg Jansen  a 
>> écrit :
>> 
>> Hi everybody,
>> 
>> when starting the karaf-container (4.3.0) on a windows server, I receive the 
>> following logging warning at startup: 
>> 
>>  org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Could not create 
>> plugin of type class org.apache.logging.log4j.core.appender.ConsoleAppender 
>> for element Console: java.util.MissingResourceException: Can't find bundle 
>> for base name Log4j-charsets, locale en_US
>>   org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Unable to invoke 
>> factory method in class 
>> org.apache.logging.log4j.core.appender.ConsoleAppender for element Console: 
>> java.lang.IllegalStateException: No factory method found for class 
>> org.apache.logging.log4j.core.appender.ConsoleAppender
>>   org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Null object 
>> returned for Console in Appenders.
>>   org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Unable to locate 
>> appender "Console" for logger config "root"
>> 
>> It doesn't matter, if it's startet as a common user or administrator. 
>> 
>> It only appears on this dedicated server, which is Windows Server 2019 
>> Standard in version 10.0.17763.
>> The used Java derivat is AdoptOpenJDK-8 (8.0.222.10-hotspot jre)
>> 
>> Does anybody has an idea where to search for a reason?
>> 
>> Thanks in advance,
>> Joerg
>> 
>> ---
>> Joerg Jansen
>> Aviation Division
>> 
>> INFORM GmbH / Pascalstr. 35 / 52076 Aachen / Germany Office +49 (0)
>> 2408/9456-3894 / Mobile+49 (0) 151-52657435 
>> joerg.jan...@inform-software.com / www.inform-software.com
>> 
>> INFORM Institut f. Operations Research und Management GmbH Registered 
>> AmtsG Aachen HRB1144 Co-CEO Adrian Weiler / Dr. Andreas Meyer / Dr.
>> Joerg Herbers / Matthias Berlit / Peter Frerichs
>> 
> 

RE: log4j warning at startup

[Jörg Jansen]

Hi JB, 

Just found a solution. 
Setting system property -Dsun.stdout.encoding=UTF-8 solved the issue. 

Regards,
Joerg

-Original Message-
From: Jörg Jansen 
Sent: Mittwoch, 17. Februar 2021 15:03
To: user 
Subject: RE: log4j warning at startup

Hi JB, 

yes, I tried with the original downloaded  (and unmodified!) assembly. 
The strange thing is, that it seems only to be present on the Windows server 
edition. 
On my local workstation (win 10) it's also working fine. 

Comparing the classpath and locale settings show no difference.

Regards,
Joerg

-Original Message-
From: Jean-Baptiste Onofre 
Sent: Mittwoch, 17. Februar 2021 14:22
To: user 
Subject: Re: log4j warning at startup

Hi Joerg,

I didn’t see such ERROR message (ok, I’m not using Windows ;)).

Are you using the default etc/org.ops4j.pax.logging.cfg ?

Regards
JB

> Le 17 févr. 2021 à 12:19, Jörg Jansen  a 
> écrit :
> 
> Hi everybody,
> 
> when starting the karaf-container (4.3.0) on a windows server, I receive the 
> following logging warning at startup: 
> 
>   org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Could not create 
> plugin of type class org.apache.logging.log4j.core.appender.ConsoleAppender 
> for element Console: java.util.MissingResourceException: Can't find bundle 
> for base name Log4j-charsets, locale en_US
>org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Unable to invoke 
> factory method in class 
> org.apache.logging.log4j.core.appender.ConsoleAppender for element Console: 
> java.lang.IllegalStateException: No factory method found for class 
> org.apache.logging.log4j.core.appender.ConsoleAppender
>org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Null object 
> returned for Console in Appenders.
>org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Unable to locate 
> appender "Console" for logger config "root"
> 
> It doesn't matter, if it's startet as a common user or administrator. 
> 
> It only appears on this dedicated server, which is Windows Server 2019 
> Standard in version 10.0.17763.
> The used Java derivat is AdoptOpenJDK-8 (8.0.222.10-hotspot jre)
> 
> Does anybody has an idea where to search for a reason?
> 
> Thanks in advance,
> Joerg
> 
> ---
> Joerg Jansen
> Aviation Division
> 
> INFORM GmbH / Pascalstr. 35 / 52076 Aachen / Germany Office +49 (0)
> 2408/9456-3894 / Mobile+49 (0) 151-52657435 
> joerg.jan...@inform-software.com / www.inform-software.com
> 
> INFORM Institut f. Operations Research und Management GmbH Registered 
> AmtsG Aachen HRB1144 Co-CEO Adrian Weiler / Dr. Andreas Meyer / Dr.
> Joerg Herbers / Matthias Berlit / Peter Frerichs
> 

RE: log4j warning at startup

[Jörg Jansen]

Hi JB, 

yes, I tried with the original downloaded  (and unmodified!) assembly. 
The strange thing is, that it seems only to be present on the Windows server 
edition. 
On my local workstation (win 10) it's also working fine. 

Comparing the classpath and locale settings show no difference.

Regards,
Joerg

-Original Message-
From: Jean-Baptiste Onofre  
Sent: Mittwoch, 17. Februar 2021 14:22
To: user 
Subject: Re: log4j warning at startup

Hi Joerg,

I didn’t see such ERROR message (ok, I’m not using Windows ;)).

Are you using the default etc/org.ops4j.pax.logging.cfg ?

Regards
JB

> Le 17 févr. 2021 à 12:19, Jörg Jansen  a 
> écrit :
> 
> Hi everybody,
> 
> when starting the karaf-container (4.3.0) on a windows server, I receive the 
> following logging warning at startup: 
> 
>   org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Could not create 
> plugin of type class org.apache.logging.log4j.core.appender.ConsoleAppender 
> for element Console: java.util.MissingResourceException: Can't find bundle 
> for base name Log4j-charsets, locale en_US
>org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Unable to invoke 
> factory method in class 
> org.apache.logging.log4j.core.appender.ConsoleAppender for element Console: 
> java.lang.IllegalStateException: No factory method found for class 
> org.apache.logging.log4j.core.appender.ConsoleAppender
>org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Null object 
> returned for Console in Appenders.
>org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Unable to locate 
> appender "Console" for logger config "root"
> 
> It doesn't matter, if it's startet as a common user or administrator. 
> 
> It only appears on this dedicated server, which is Windows Server 2019 
> Standard in version 10.0.17763.
> The used Java derivat is AdoptOpenJDK-8 (8.0.222.10-hotspot jre)
> 
> Does anybody has an idea where to search for a reason?
> 
> Thanks in advance,
> Joerg
> 
> ---
> Joerg Jansen
> Aviation Division
> 
> INFORM GmbH / Pascalstr. 35 / 52076 Aachen / Germany Office +49 (0) 
> 2408/9456-3894 / Mobile+49 (0) 151-52657435 
> joerg.jan...@inform-software.com / www.inform-software.com
> 
> INFORM Institut f. Operations Research und Management GmbH Registered 
> AmtsG Aachen HRB1144 Co-CEO Adrian Weiler / Dr. Andreas Meyer / Dr. 
> Joerg Herbers / Matthias Berlit / Peter Frerichs
> 

Re: log4j warning at startup

[Jean-Baptiste Onofre]

Hi Joerg,

I didn’t see such ERROR message (ok, I’m not using Windows ;)).

Are you using the default etc/org.ops4j.pax.logging.cfg ?

Regards
JB

> Le 17 févr. 2021 à 12:19, Jörg Jansen  a 
> écrit :
> 
> Hi everybody,
> 
> when starting the karaf-container (4.3.0) on a windows server, I receive the 
> following logging warning at startup: 
> 
>   org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Could not create 
> plugin of type class org.apache.logging.log4j.core.appender.ConsoleAppender 
> for element Console: java.util.MissingResourceException: Can't find bundle 
> for base name Log4j-charsets, locale en_US
>org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Unable to invoke 
> factory method in class 
> org.apache.logging.log4j.core.appender.ConsoleAppender for element Console: 
> java.lang.IllegalStateException: No factory method found for class 
> org.apache.logging.log4j.core.appender.ConsoleAppender
>org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Null object 
> returned for Console in Appenders.
>org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Unable to locate 
> appender "Console" for logger config "root"
> 
> It doesn't matter, if it's startet as a common user or administrator. 
> 
> It only appears on this dedicated server, which is Windows Server 2019 
> Standard in version 10.0.17763.
> The used Java derivat is AdoptOpenJDK-8 (8.0.222.10-hotspot jre)
> 
> Does anybody has an idea where to search for a reason?
> 
> Thanks in advance, 
> Joerg
> 
> ---
> Joerg Jansen
> Aviation Division
> 
> INFORM GmbH / Pascalstr. 35 / 52076 Aachen / Germany
> Office +49 (0) 2408/9456-3894 / Mobile+49 (0) 151-52657435
> joerg.jan...@inform-software.com / www.inform-software.com
> 
> INFORM Institut f. Operations Research und Management GmbH
> Registered AmtsG Aachen HRB1144
> Co-CEO Adrian Weiler / Dr. Andreas Meyer / Dr. Joerg Herbers / Matthias 
> Berlit / Peter Frerichs
> 

log4j warning at startup

[Jörg Jansen]

Hi everybody,

when starting the karaf-container (4.3.0) on a windows server, I receive the 
following logging warning at startup: 

   org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Could not create 
plugin of type class org.apache.logging.log4j.core.appender.ConsoleAppender for 
element Console: java.util.MissingResourceException: Can't find bundle for base 
name Log4j-charsets, locale en_US
org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Unable to invoke 
factory method in class org.apache.logging.log4j.core.appender.ConsoleAppender 
for element Console: java.lang.IllegalStateException: No factory method found 
for class org.apache.logging.log4j.core.appender.ConsoleAppender
org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Null object 
returned for Console in Appenders.
org.ops4j.pax.logging.pax-logging-log4j2 [log4j2] ERROR : Unable to locate 
appender "Console" for logger config "root"

It doesn't matter, if it's startet as a common user or administrator. 

It only appears on this dedicated server, which is Windows Server 2019 Standard 
in version 10.0.17763.
The used Java derivat is AdoptOpenJDK-8 (8.0.222.10-hotspot jre)

Does anybody has an idea where to search for a reason?

Thanks in advance, 
Joerg

---
Joerg Jansen
Aviation Division

INFORM GmbH / Pascalstr. 35 / 52076 Aachen / Germany
Office +49 (0) 2408/9456-3894 / Mobile+49 (0) 151-52657435
joerg.jan...@inform-software.com / www.inform-software.com

INFORM Institut f. Operations Research und Management GmbH
Registered AmtsG Aachen HRB1144
Co-CEO Adrian Weiler / Dr. Andreas Meyer / Dr. Joerg Herbers / Matthias Berlit 
/ Peter Frerichs

Logging color is always white when using Log4j 1 with Karaf 4.1.2

[roelens8]

I am having an issue when using Log4j 1 (via pax-logging-service, version
1.10.1) with Karaf 4.1.2, where the logging color in the Karaf console (when
tailing the logs) is always white instead of the usual default colors of
purple for warn, red for error and blue for trace and info, etc.

I have followed the directions in this article
(http://tmielke.blogspot.com/2013/04/how-to-chang-colors-in-karaf-shell.html)
to attempt changing the logging color, but it did not work.

The reason I am using Log4j 1 instead of Log4j2 is because there doesn't
seem to be any support for the NTEventLogAppender in Log4j2 and I need to
forward my logs to the Windows Event Collector. So I decided to use Log4j 1
in order to keep this capability, but then I ran into this logging color
issue and it's important that the logging color still works as it's almost
impossible to read without it.  

Does anyone have suggestions on how to fix the logging color issue or know
if it's possible to get the NTEventLogAppender to work with Log4j2?







--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: JMS log4j appender

[Christian Schneider]

In your case you would have to make sure the pax logging bunde has access
to the jms api. So you would need to write a fragment for it.

An easier way is to use Apache Decanter with the jms appender. It is
already well prepared for OSGi.
See:
https://karaf.apache.org/manual/decanter/latest-1/#_jms

Christian

2017-11-25 9:39 GMT+01:00 eric56 :

> Hi,
>
> I created this appender in my org.ops4j.pax.logging.cfg file:
> *log4j.appender.JMS=org.apache.log4j.net.JMSAppender
> log4j.appender.JMS.InitialContextFactoryName=org.apache.activemq.jndi.
> ActiveMQInitialContextFactory
> log4j.appender.JMS.ProviderURL=tcp://localhost:61616
> log4j.appender.JMS.TopicBindingName=logTopic
> log4j.appender.JMS.TopicConnectionFactoryBindingName=ConnectionFactory
> log4j.appender.JMS.Threshold=ERROR*
>
> I get this error message is:
> *Unexpected problem updating configuration org.ops4j.pax.logging
> java.lang.NoClassDefFoundError: javax/jms/JMSException*
>
> I installed this additionnal bundle:
> *bundle:install mvn:javax.jms/javax.jms-api/2.0.1*
>
> But it didn't help...
>
> Currently I have this bundle installed:
> *162 | Active   |  50 | 2.16.3| camel-jms
> 279 | Active   |  80 | 4.0.5 | Apache Karaf :: JMS :: Core
> 280 | Active   |  80 | 2.0.1 | JMS API
> *
> And these features:
> *karaf@trun()> feature:list | grep -i JMS
> cxf-transports-jms  | 3.1.5 |
> |
> Started | cxf-3.1.5  |
> spring-jms  | 3.2.14.RELEASE_1  |
> |
> Started | spring-4.0.5   | Spring 3.2.x JMS
> support
> camel-jms   | 2.16.3| x
> |
> Started | camel-2.16.3   |
> jms | 4.0.5 | x
> |
> Started | enterprise-4.0.5   | JMS service and
> commands*
>
> Could you help me ?
>
> Regards.
>
> Eric
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Computer Scientist
http://www.adobe.com

Configure DecanterLogCollectorAppender with StringMatchFilter of Log4j 1.x

[Patrick Gottschämmer]

Hi Karaf – User,

 

how can i configure a Log4j StringMatchFilter for the Karaf Decanter Log
Collector?

For „manual built up“ appenders it works like this:

 

   log4j.appender.FILE=org.apache.log4j.FileAppender

   log4j.appender.FILE.File=info.log

   log4j.appender.FILE.Threshold=INFO

 
log4j.appender.FILE.filter.a=org.apache.log4j.varia.StringMatchFilter

   log4j.appender.FILE.filter.a.StringToMatch=“someString“

   log4j.appender.FILE.filter.a.AcceptOnMatch=false

 

However, it seems like I can't "access" the DecanterLogCollectorAppender
since its loaded via osgi:DecanterLogCollectorAppender (or similar osgi:*).

Also, creating it manually with 

 

 
log4j.appender.decanter=org.apache.karaf.decanter.collector.log.LogAppender
or org.apache.karaf.decanter.collector.log.DecanterLogCollectorAppender)

 

also doesn't work. But there must be a way in Karaf to configure osgi:
loaded appenders, right?

 

--

Patrick Gottschaemmer

Development Director 

 

Venture Services Seeheim GmbH

Bessunger Straße 83 | 64285 Darmstadt | Germany

Tel.: +49 160 97056295 |  <mailto:p...@vs-sh.de> p...@vs-sh.de

 

 

Re: Connect pax-logging/Log4j with 3rd party Jar

[Althaus, Volker]

Hi Guillaume,
Thanks for reply. Unfortunately this is exactly the bundle setup I've used so 
far.
I am not happy with that because I have to maintain two log4j configurations, 
therefore I am searching for a solution to integrate pax-logging somehow.


Regards


Von: Guillaume Nodet [mailto:gno...@apache.org] 
Gesendet: Montag, 25. Juli 2016 09:30
An: user <user@karaf.apache.org>
Betreff: Re: Connect pax-logging/Log4j with 3rd party Jar

In such a case, one possibility would be to create an uber bundle containing 
the library + an embedded version of log4j, without importing the package.  It 
will force that library to use the embedded version of log4j which will be 
complete. So you won't run into ClassNotFoundException, but the logging will 
not go through pax-logging.

Guillaume

2016-07-22 10:15 GMT+02:00 Althaus, Volker <v.alth...@cenit.de>:
Hi,
I have a non-OSGI 3rd party Jar which seems to use Log4j in a way that I cannot 
connect it to Pax-Logging.

I followed the instructions in 
https://ops4j1.jira.com/wiki/display/paxlogging/How+to+use+Pax+Logging+in+my+bundles

I created a wrapper bundle without the log4j Jar and made an import 
"org.apache.log4j;provider=paxlogging".

The problem is that, under some circumstances, the 3rd party library creates 
Loggers and Appenders programmatically, for example:

import org.apache.log4j.PatternLayout;
...
Logger logger = Logger.getRootLogger();
ConsoleAppender appender = new ConsoleAppender();
PatternLayout layout = new PatternLayout("%d %5p [%t] - %m%n");

With this code I end up with a ClassNotFoundException: org.apache.log4.Layout.

This makes sense as the pax-logging-api bundle in Karaf exports the 
org.apache.log4j package, but it does not contain the Layout class.
The Layout class is in the pax-logging-service bundle instead, but the package 
is not exported from there.

I also tried to include the log4j Jar again to have the Layout class available 
on the classpath, but ended up with the same Exception.

Anybody an idea how I can get this scenario to run without requesting the 
manufacturer of that library to change the code?


TIA & Regards
  Volker


CENIT AG, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49 711 7825-30, Fax: 
+49 711 7825-4000, Internet: www.cenit.com
Geschaeftsstellen: Berlin, Frankfurt, Hamburg, Hannover, Muenchen, Oelsnitz, 
Ratingen, Saarbruecken
Vorstandsmitglieder: Kurt Bengel, Matthias Schmidt
Aufsichtsratsmitglieder: Andreas Schmidt (Vorsitzender des Aufsichtsrats), 
Hubert Leypoldt, Andreas Karrer
Bankverbindungen:
Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : DE85 6007 0070 0166 1040 00 
SWIFT-CODE : DEUTDESS,
Commerzbank (BLZ 600 400 71) Kto. 532 015 500 IBAN : DE83 6004 0071 0532 0155 
00 SWIFT-Code : COBADEFF600,
Registergericht: Amtsgericht Stuttgart
Handelsregister: HRB Nr. 19117
Umsatzsteuer: ID-Nr. DE 147 862 777




-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/


CENIT AG, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49 711 7825-30, Fax: 
+49 711 7825-4000, Internet: www.cenit.com
Geschaeftsstellen: Berlin, Frankfurt, Hamburg, Hannover, Muenchen, Oelsnitz, 
Ratingen, Saarbruecken
Vorstandsmitglieder: Kurt Bengel, Matthias Schmidt
Aufsichtsratsmitglieder: Andreas Schmidt (Vorsitzender des Aufsichtsrats), 
Hubert Leypoldt, Andreas Karrer
Bankverbindungen:
Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : DE85 6007 0070 0166 1040 00 
SWIFT-CODE : DEUTDESS,
Commerzbank (BLZ 600 400 71) Kto. 532 015 500 IBAN : DE83 6004 0071 0532 0155 
00 SWIFT-Code : COBADEFF600,
Registergericht: Amtsgericht Stuttgart
Handelsregister: HRB Nr. 19117
Umsatzsteuer: ID-Nr. DE 147 862 777

Re: Connect pax-logging/Log4j with 3rd party Jar

[Guillaume Nodet]

In such a case, one possibility would be to create an uber bundle
containing the library + an embedded version of log4j, without importing
the package.  It will force that library to use the embedded version of
log4j which will be complete. So you won't run into ClassNotFoundException,
but the logging will not go through pax-logging.

Guillaume

2016-07-22 10:15 GMT+02:00 Althaus, Volker <v.alth...@cenit.de>:

> Hi,
> I have a non-OSGI 3rd party Jar which seems to use Log4j in a way that I
> cannot connect it to Pax-Logging.
>
> I followed the instructions in
> https://ops4j1.jira.com/wiki/display/paxlogging/How+to+use+Pax+Logging+in+my+bundles
>
> I created a wrapper bundle without the log4j Jar and made an import
> "org.apache.log4j;provider=paxlogging".
>
> The problem is that, under some circumstances, the 3rd party library
> creates Loggers and Appenders programmatically, for example:
>
> import org.apache.log4j.PatternLayout;
> ...
> Logger logger = Logger.getRootLogger();
> ConsoleAppender appender = new ConsoleAppender();
> PatternLayout layout = new PatternLayout("%d %5p [%t] - %m%n");
>
> With this code I end up with a ClassNotFoundException:
> org.apache.log4.Layout.
>
> This makes sense as the pax-logging-api bundle in Karaf exports the
> org.apache.log4j package, but it does not contain the Layout class.
> The Layout class is in the pax-logging-service bundle instead, but the
> package is not exported from there.
>
> I also tried to include the log4j Jar again to have the Layout class
> available on the classpath, but ended up with the same Exception.
>
> Anybody an idea how I can get this scenario to run without requesting the
> manufacturer of that library to change the code?
>
>
> TIA & Regards
>   Volker
>
>
> CENIT AG, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49 711 7825-30,
> Fax: +49 711 7825-4000, Internet: www.cenit.com
> Geschaeftsstellen: Berlin, Frankfurt, Hamburg, Hannover, Muenchen,
> Oelsnitz, Ratingen, Saarbruecken
> Vorstandsmitglieder: Kurt Bengel, Matthias Schmidt
> Aufsichtsratsmitglieder: Andreas Schmidt (Vorsitzender des Aufsichtsrats),
> Hubert Leypoldt, Andreas Karrer
> Bankverbindungen:
> Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : DE85 6007 0070 0166
> 1040 00 SWIFT-CODE : DEUTDESS,
> Commerzbank (BLZ 600 400 71) Kto. 532 015 500 IBAN : DE83 6004 0071 0532
> 0155 00 SWIFT-Code : COBADEFF600,
> Registergericht: Amtsgericht Stuttgart
> Handelsregister: HRB Nr. 19117
> Umsatzsteuer: ID-Nr. DE 147 862 777
>
>


-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Connect pax-logging/Log4j with 3rd party Jar

[Althaus, Volker]

Hi,
I have a non-OSGI 3rd party Jar which seems to use Log4j in a way that I cannot 
connect it to Pax-Logging.

I followed the instructions in 
https://ops4j1.jira.com/wiki/display/paxlogging/How+to+use+Pax+Logging+in+my+bundles

I created a wrapper bundle without the log4j Jar and made an import 
"org.apache.log4j;provider=paxlogging".

The problem is that, under some circumstances, the 3rd party library creates 
Loggers and Appenders programmatically, for example:

import org.apache.log4j.PatternLayout;
...
Logger logger = Logger.getRootLogger();
ConsoleAppender appender = new ConsoleAppender();
PatternLayout layout = new PatternLayout("%d %5p [%t] - %m%n");

With this code I end up with a ClassNotFoundException: org.apache.log4.Layout.

This makes sense as the pax-logging-api bundle in Karaf exports the 
org.apache.log4j package, but it does not contain the Layout class.
The Layout class is in the pax-logging-service bundle instead, but the package 
is not exported from there.

I also tried to include the log4j Jar again to have the Layout class available 
on the classpath, but ended up with the same Exception.

Anybody an idea how I can get this scenario to run without requesting the 
manufacturer of that library to change the code?


TIA & Regards
  Volker
 

CENIT AG, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49 711 7825-30, Fax: 
+49 711 7825-4000, Internet: www.cenit.com
Geschaeftsstellen: Berlin, Frankfurt, Hamburg, Hannover, Muenchen, Oelsnitz, 
Ratingen, Saarbruecken
Vorstandsmitglieder: Kurt Bengel, Matthias Schmidt
Aufsichtsratsmitglieder: Andreas Schmidt (Vorsitzender des Aufsichtsrats), 
Hubert Leypoldt, Andreas Karrer
Bankverbindungen:
Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : DE85 6007 0070 0166 1040 00 
SWIFT-CODE : DEUTDESS,
Commerzbank (BLZ 600 400 71) Kto. 532 015 500 IBAN : DE83 6004 0071 0532 0155 
00 SWIFT-Code : COBADEFF600,
Registergericht: Amtsgericht Stuttgart
Handelsregister: HRB Nr. 19117
Umsatzsteuer: ID-Nr. DE 147 862 777

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Bengt Rodehav]

OK - thanks for trying.

/Bengt

2016-07-12 11:12 GMT+02:00 Achim Nierbeck <bcanh...@googlemail.com>:

> Hi Bengt,
>
> sorry been very busy lately. I did give it a try but couldn't find a
> reason why Log4j2 should be used or Pax Logging should be triggered to be
> restarted. There isn't any reason for the pax web bundles to do so ... :/
> sorry didn't get any further on this ..
>
> regards, Achim
>
>
>
>
> 2016-07-11 14:47 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>
>> Did you have a chance to look at this Achim? If there is a problem with
>> the pax-jetty feature it would be nice to have it fixed in Karaf 4.0.6
>> which I understand is in the works.
>>
>> /Bengt
>>
>> 2016-07-07 9:13 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>
>>> OK - thanks Achim,
>>>
>>> /Bengt
>>>
>>> 2016-07-06 22:08 GMT+02:00 Achim Nierbeck <bcanh...@googlemail.com>:
>>>
>>>> Hi Bengt,
>>>>
>>>> I'll try to find out if one of the bundles in that feature depends on
>>>> log4j2 ... but I'm not aware of such a dependency.
>>>>
>>>> Your suspicion about dynamic loading of DLLs is correct in case of the
>>>> location of the dll is inside of a bundle and does have dependencies to
>>>> another dll. If it's a dll loaded via the root classloader that shouldn't
>>>> be of an issue.
>>>>
>>>> regards, Achim
>>>>
>>>>
>>>> 2016-07-04 16:04 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>>>
>>>>> Another theory: Looking at the stack trace this seems to be triggered
>>>>> by a configuration update. Could the problem be that Pax-logging is trying
>>>>> to load the DLL again and failing since it is already loaded? Perhaps the
>>>>> initial load works but subsequent configuration updates does not?
>>>>>
>>>>> I tried to verify this...
>>>>>
>>>>> After successful start of Karaf (after step 9 in my previous post), I
>>>>> edit org.ops4j.pas.logging.cfg (by changing the root logger between INFO
>>>>> and DEBUG). This causes no error.
>>>>>
>>>>> But after having installed feature pax-jetty (after step 10 in my
>>>>> previous post), every change in org.ops4j.pas.logging.cfg causes the same
>>>>> error to appear (the stack trace included in my previous post).
>>>>>
>>>>> It's as if installing the pax-jetty feature takes gives control of
>>>>> org.ops4j.pas.logging.cfg to someone who cannot load the DLL. I have no
>>>>> idea how this could happen.
>>>>>
>>>>> Anyone else has an idea?
>>>>>
>>>>> /Bengt
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> /Bengt
>>>>>
>>>>> 2016-07-04 15:51 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>>>>
>>>>>> A theory: Could one of the bundles installed by feature pax-jetty be
>>>>>> using log4j 2.x directly without using Pax-logging? If so, would it too 
>>>>>> try
>>>>>> to read the log4j configuration file? I guess it would fail to load the 
>>>>>> DLL
>>>>>> since it is probably not compatible with log4j 2.x.
>>>>>>
>>>>>> Could this happen? If so, how can I find out which bundle?
>>>>>>
>>>>>> /Bengt
>>>>>>
>>>>>> 2016-07-04 15:15 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>>>>>
>>>>>>> Back to the Karaf mailing list
>>>>>>>
>>>>>>> I can actually get this problem on a standard vanilla Karaf 4.0.5.
>>>>>>> It seems to be triggered when installing the feature pax-jetty.
>>>>>>>
>>>>>>> *1. Install standard Karaf 4.0.5*
>>>>>>>
>>>>>>> *2. Replace org.ops4j.pax.logging.cfg with the following:*
>>>>>>>
>>>>>>> log4j.rootLogger=INFO, stdout
>>>>>>>
>>>>>>> # CONSOLE appender
>>>>>>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>>>>>>> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>>>>>

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Achim Nierbeck]

Hi Bengt,

sorry been very busy lately. I did give it a try but couldn't find a reason
why Log4j2 should be used or Pax Logging should be triggered to be
restarted. There isn't any reason for the pax web bundles to do so ... :/
sorry didn't get any further on this ..

regards, Achim




2016-07-11 14:47 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:

> Did you have a chance to look at this Achim? If there is a problem with
> the pax-jetty feature it would be nice to have it fixed in Karaf 4.0.6
> which I understand is in the works.
>
> /Bengt
>
> 2016-07-07 9:13 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>
>> OK - thanks Achim,
>>
>> /Bengt
>>
>> 2016-07-06 22:08 GMT+02:00 Achim Nierbeck <bcanh...@googlemail.com>:
>>
>>> Hi Bengt,
>>>
>>> I'll try to find out if one of the bundles in that feature depends on
>>> log4j2 ... but I'm not aware of such a dependency.
>>>
>>> Your suspicion about dynamic loading of DLLs is correct in case of the
>>> location of the dll is inside of a bundle and does have dependencies to
>>> another dll. If it's a dll loaded via the root classloader that shouldn't
>>> be of an issue.
>>>
>>> regards, Achim
>>>
>>>
>>> 2016-07-04 16:04 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>>
>>>> Another theory: Looking at the stack trace this seems to be triggered
>>>> by a configuration update. Could the problem be that Pax-logging is trying
>>>> to load the DLL again and failing since it is already loaded? Perhaps the
>>>> initial load works but subsequent configuration updates does not?
>>>>
>>>> I tried to verify this...
>>>>
>>>> After successful start of Karaf (after step 9 in my previous post), I
>>>> edit org.ops4j.pas.logging.cfg (by changing the root logger between INFO
>>>> and DEBUG). This causes no error.
>>>>
>>>> But after having installed feature pax-jetty (after step 10 in my
>>>> previous post), every change in org.ops4j.pas.logging.cfg causes the same
>>>> error to appear (the stack trace included in my previous post).
>>>>
>>>> It's as if installing the pax-jetty feature takes gives control of
>>>> org.ops4j.pas.logging.cfg to someone who cannot load the DLL. I have no
>>>> idea how this could happen.
>>>>
>>>> Anyone else has an idea?
>>>>
>>>> /Bengt
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> /Bengt
>>>>
>>>> 2016-07-04 15:51 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>>>
>>>>> A theory: Could one of the bundles installed by feature pax-jetty be
>>>>> using log4j 2.x directly without using Pax-logging? If so, would it too 
>>>>> try
>>>>> to read the log4j configuration file? I guess it would fail to load the 
>>>>> DLL
>>>>> since it is probably not compatible with log4j 2.x.
>>>>>
>>>>> Could this happen? If so, how can I find out which bundle?
>>>>>
>>>>> /Bengt
>>>>>
>>>>> 2016-07-04 15:15 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>>>>
>>>>>> Back to the Karaf mailing list
>>>>>>
>>>>>> I can actually get this problem on a standard vanilla Karaf 4.0.5. It
>>>>>> seems to be triggered when installing the feature pax-jetty.
>>>>>>
>>>>>> *1. Install standard Karaf 4.0.5*
>>>>>>
>>>>>> *2. Replace org.ops4j.pax.logging.cfg with the following:*
>>>>>>
>>>>>> log4j.rootLogger=INFO, stdout
>>>>>>
>>>>>> # CONSOLE appender
>>>>>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>>>>>> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>>>>>> log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p |
>>>>>> %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
>>>>>> log4j.appender.stdout.threshold=ERROR
>>>>>>
>>>>>> # Windows event log
>>>>>> log4j.appender.nteventlog=org.apache.log4j.nt.NTEventLogAppender
>>>>>> log4j.appender.nteventlog.source=Test source
>>>>>> log4j.appender.nteventlog.layout=org.apach

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Bengt Rodehav]

Did you have a chance to look at this Achim? If there is a problem with the
pax-jetty feature it would be nice to have it fixed in Karaf 4.0.6 which I
understand is in the works.

/Bengt

2016-07-07 9:13 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:

> OK - thanks Achim,
>
> /Bengt
>
> 2016-07-06 22:08 GMT+02:00 Achim Nierbeck <bcanh...@googlemail.com>:
>
>> Hi Bengt,
>>
>> I'll try to find out if one of the bundles in that feature depends on
>> log4j2 ... but I'm not aware of such a dependency.
>>
>> Your suspicion about dynamic loading of DLLs is correct in case of the
>> location of the dll is inside of a bundle and does have dependencies to
>> another dll. If it's a dll loaded via the root classloader that shouldn't
>> be of an issue.
>>
>> regards, Achim
>>
>>
>> 2016-07-04 16:04 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>
>>> Another theory: Looking at the stack trace this seems to be triggered by
>>> a configuration update. Could the problem be that Pax-logging is trying to
>>> load the DLL again and failing since it is already loaded? Perhaps the
>>> initial load works but subsequent configuration updates does not?
>>>
>>> I tried to verify this...
>>>
>>> After successful start of Karaf (after step 9 in my previous post), I
>>> edit org.ops4j.pas.logging.cfg (by changing the root logger between INFO
>>> and DEBUG). This causes no error.
>>>
>>> But after having installed feature pax-jetty (after step 10 in my
>>> previous post), every change in org.ops4j.pas.logging.cfg causes the same
>>> error to appear (the stack trace included in my previous post).
>>>
>>> It's as if installing the pax-jetty feature takes gives control of
>>> org.ops4j.pas.logging.cfg to someone who cannot load the DLL. I have no
>>> idea how this could happen.
>>>
>>> Anyone else has an idea?
>>>
>>> /Bengt
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> /Bengt
>>>
>>> 2016-07-04 15:51 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>>
>>>> A theory: Could one of the bundles installed by feature pax-jetty be
>>>> using log4j 2.x directly without using Pax-logging? If so, would it too try
>>>> to read the log4j configuration file? I guess it would fail to load the DLL
>>>> since it is probably not compatible with log4j 2.x.
>>>>
>>>> Could this happen? If so, how can I find out which bundle?
>>>>
>>>> /Bengt
>>>>
>>>> 2016-07-04 15:15 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>>>
>>>>> Back to the Karaf mailing list
>>>>>
>>>>> I can actually get this problem on a standard vanilla Karaf 4.0.5. It
>>>>> seems to be triggered when installing the feature pax-jetty.
>>>>>
>>>>> *1. Install standard Karaf 4.0.5*
>>>>>
>>>>> *2. Replace org.ops4j.pax.logging.cfg with the following:*
>>>>>
>>>>> log4j.rootLogger=INFO, stdout
>>>>>
>>>>> # CONSOLE appender
>>>>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>>>>> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>>>>> log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p |
>>>>> %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
>>>>> log4j.appender.stdout.threshold=ERROR
>>>>>
>>>>> # Windows event log
>>>>> log4j.appender.nteventlog=org.apache.log4j.nt.NTEventLogAppender
>>>>> log4j.appender.nteventlog.source=Test source
>>>>> log4j.appender.nteventlog.layout=org.apache.log4j.PatternLayout
>>>>> log4j.appender.nteventlog.layout.ConversionPattern=Time:
>>>>> %d{ISO8601}%n%nSeverity: %p%n%nThread: %t%n%n%m%n
>>>>> log4j.appender.nteventlog.threshold=DEBUG
>>>>>
>>>>> *3. Start Karaf: "bin\karaf clean"*
>>>>>
>>>>> This should work.
>>>>>
>>>>> *4. Exit Karaf*
>>>>>
>>>>> *5. Change the root looger line to:*
>>>>>
>>>>> log4j.rootLogger=INFO, stdout, nteventlog
>>>>>
>>>>> *6. Start Karaf again*
>>>>>
>>>>> I get the following error:
>>>>>
>>>>> 2016-07-04 15:05:39,53

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Bengt Rodehav]

OK - thanks Achim,

/Bengt

2016-07-06 22:08 GMT+02:00 Achim Nierbeck <bcanh...@googlemail.com>:

> Hi Bengt,
>
> I'll try to find out if one of the bundles in that feature depends on
> log4j2 ... but I'm not aware of such a dependency.
>
> Your suspicion about dynamic loading of DLLs is correct in case of the
> location of the dll is inside of a bundle and does have dependencies to
> another dll. If it's a dll loaded via the root classloader that shouldn't
> be of an issue.
>
> regards, Achim
>
>
> 2016-07-04 16:04 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>
>> Another theory: Looking at the stack trace this seems to be triggered by
>> a configuration update. Could the problem be that Pax-logging is trying to
>> load the DLL again and failing since it is already loaded? Perhaps the
>> initial load works but subsequent configuration updates does not?
>>
>> I tried to verify this...
>>
>> After successful start of Karaf (after step 9 in my previous post), I
>> edit org.ops4j.pas.logging.cfg (by changing the root logger between INFO
>> and DEBUG). This causes no error.
>>
>> But after having installed feature pax-jetty (after step 10 in my
>> previous post), every change in org.ops4j.pas.logging.cfg causes the same
>> error to appear (the stack trace included in my previous post).
>>
>> It's as if installing the pax-jetty feature takes gives control of
>> org.ops4j.pas.logging.cfg to someone who cannot load the DLL. I have no
>> idea how this could happen.
>>
>> Anyone else has an idea?
>>
>> /Bengt
>>
>>
>>
>>
>>
>>
>>
>> /Bengt
>>
>> 2016-07-04 15:51 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>
>>> A theory: Could one of the bundles installed by feature pax-jetty be
>>> using log4j 2.x directly without using Pax-logging? If so, would it too try
>>> to read the log4j configuration file? I guess it would fail to load the DLL
>>> since it is probably not compatible with log4j 2.x.
>>>
>>> Could this happen? If so, how can I find out which bundle?
>>>
>>> /Bengt
>>>
>>> 2016-07-04 15:15 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>>
>>>> Back to the Karaf mailing list
>>>>
>>>> I can actually get this problem on a standard vanilla Karaf 4.0.5. It
>>>> seems to be triggered when installing the feature pax-jetty.
>>>>
>>>> *1. Install standard Karaf 4.0.5*
>>>>
>>>> *2. Replace org.ops4j.pax.logging.cfg with the following:*
>>>>
>>>> log4j.rootLogger=INFO, stdout
>>>>
>>>> # CONSOLE appender
>>>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>>>> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>>>> log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p |
>>>> %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
>>>> log4j.appender.stdout.threshold=ERROR
>>>>
>>>> # Windows event log
>>>> log4j.appender.nteventlog=org.apache.log4j.nt.NTEventLogAppender
>>>> log4j.appender.nteventlog.source=Test source
>>>> log4j.appender.nteventlog.layout=org.apache.log4j.PatternLayout
>>>> log4j.appender.nteventlog.layout.ConversionPattern=Time:
>>>> %d{ISO8601}%n%nSeverity: %p%n%nThread: %t%n%n%m%n
>>>> log4j.appender.nteventlog.threshold=DEBUG
>>>>
>>>> *3. Start Karaf: "bin\karaf clean"*
>>>>
>>>> This should work.
>>>>
>>>> *4. Exit Karaf*
>>>>
>>>> *5. Change the root looger line to:*
>>>>
>>>> log4j.rootLogger=INFO, stdout, nteventlog
>>>>
>>>> *6. Start Karaf again*
>>>>
>>>> I get the following error:
>>>>
>>>> 2016-07-04 15:05:39,534 | ERROR | s4j.pax.logging) | configadmin
>>>>| ?? | [org.osgi.service.log.LogService,
>>>> org.knopflerfish.service.log.LogService,
>>>> org.ops4j.pax.logging.PaxLoggingService,
>>>> org.osgi.service.cm.ManagedService, id=12,
>>>> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]: Unexpected
>>>> problem updating configuration org.ops4j.pax.logging
>>>> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in
>>>> java.library.path
>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
>>>> at java.la

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Achim Nierbeck]

Hi Bengt,

I'll try to find out if one of the bundles in that feature depends on
log4j2 ... but I'm not aware of such a dependency.

Your suspicion about dynamic loading of DLLs is correct in case of the
location of the dll is inside of a bundle and does have dependencies to
another dll. If it's a dll loaded via the root classloader that shouldn't
be of an issue.

regards, Achim


2016-07-04 16:04 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:

> Another theory: Looking at the stack trace this seems to be triggered by a
> configuration update. Could the problem be that Pax-logging is trying to
> load the DLL again and failing since it is already loaded? Perhaps the
> initial load works but subsequent configuration updates does not?
>
> I tried to verify this...
>
> After successful start of Karaf (after step 9 in my previous post), I edit
> org.ops4j.pas.logging.cfg (by changing the root logger between INFO and
> DEBUG). This causes no error.
>
> But after having installed feature pax-jetty (after step 10 in my previous
> post), every change in org.ops4j.pas.logging.cfg causes the same error to
> appear (the stack trace included in my previous post).
>
> It's as if installing the pax-jetty feature takes gives control of
> org.ops4j.pas.logging.cfg to someone who cannot load the DLL. I have no
> idea how this could happen.
>
> Anyone else has an idea?
>
> /Bengt
>
>
>
>
>
>
>
> /Bengt
>
> 2016-07-04 15:51 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>
>> A theory: Could one of the bundles installed by feature pax-jetty be
>> using log4j 2.x directly without using Pax-logging? If so, would it too try
>> to read the log4j configuration file? I guess it would fail to load the DLL
>> since it is probably not compatible with log4j 2.x.
>>
>> Could this happen? If so, how can I find out which bundle?
>>
>> /Bengt
>>
>> 2016-07-04 15:15 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>
>>> Back to the Karaf mailing list
>>>
>>> I can actually get this problem on a standard vanilla Karaf 4.0.5. It
>>> seems to be triggered when installing the feature pax-jetty.
>>>
>>> *1. Install standard Karaf 4.0.5*
>>>
>>> *2. Replace org.ops4j.pax.logging.cfg with the following:*
>>>
>>> log4j.rootLogger=INFO, stdout
>>>
>>> # CONSOLE appender
>>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>>> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>>> log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p |
>>> %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
>>> log4j.appender.stdout.threshold=ERROR
>>>
>>> # Windows event log
>>> log4j.appender.nteventlog=org.apache.log4j.nt.NTEventLogAppender
>>> log4j.appender.nteventlog.source=Test source
>>> log4j.appender.nteventlog.layout=org.apache.log4j.PatternLayout
>>> log4j.appender.nteventlog.layout.ConversionPattern=Time:
>>> %d{ISO8601}%n%nSeverity: %p%n%nThread: %t%n%n%m%n
>>> log4j.appender.nteventlog.threshold=DEBUG
>>>
>>> *3. Start Karaf: "bin\karaf clean"*
>>>
>>> This should work.
>>>
>>> *4. Exit Karaf*
>>>
>>> *5. Change the root looger line to:*
>>>
>>> log4j.rootLogger=INFO, stdout, nteventlog
>>>
>>> *6. Start Karaf again*
>>>
>>> I get the following error:
>>>
>>> 2016-07-04 15:05:39,534 | ERROR | s4j.pax.logging) | configadmin
>>>  | ?? | [org.osgi.service.log.LogService,
>>> org.knopflerfish.service.log.LogService,
>>> org.ops4j.pax.logging.PaxLoggingService,
>>> org.osgi.service.cm.ManagedService, id=12,
>>> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]: Unexpected
>>> problem updating configuration org.ops4j.pax.logging
>>> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in
>>> java.library.path
>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>> at java.lang.System.loadLibrary(System.java:1122)
>>> at
>>> org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>> Method)
>>> at
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>> at
>>> sun.reflect.DelegatingConstructorAcce

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Bengt Rodehav]

Another theory: Looking at the stack trace this seems to be triggered by a
configuration update. Could the problem be that Pax-logging is trying to
load the DLL again and failing since it is already loaded? Perhaps the
initial load works but subsequent configuration updates does not?

I tried to verify this...

After successful start of Karaf (after step 9 in my previous post), I edit
org.ops4j.pas.logging.cfg (by changing the root logger between INFO and
DEBUG). This causes no error.

But after having installed feature pax-jetty (after step 10 in my previous
post), every change in org.ops4j.pas.logging.cfg causes the same error to
appear (the stack trace included in my previous post).

It's as if installing the pax-jetty feature takes gives control of
org.ops4j.pas.logging.cfg to someone who cannot load the DLL. I have no
idea how this could happen.

Anyone else has an idea?

/Bengt







/Bengt

2016-07-04 15:51 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:

> A theory: Could one of the bundles installed by feature pax-jetty be using
> log4j 2.x directly without using Pax-logging? If so, would it too try to
> read the log4j configuration file? I guess it would fail to load the DLL
> since it is probably not compatible with log4j 2.x.
>
> Could this happen? If so, how can I find out which bundle?
>
> /Bengt
>
> 2016-07-04 15:15 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>
>> Back to the Karaf mailing list
>>
>> I can actually get this problem on a standard vanilla Karaf 4.0.5. It
>> seems to be triggered when installing the feature pax-jetty.
>>
>> *1. Install standard Karaf 4.0.5*
>>
>> *2. Replace org.ops4j.pax.logging.cfg with the following:*
>>
>> log4j.rootLogger=INFO, stdout
>>
>> # CONSOLE appender
>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>> log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p |
>> %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
>> log4j.appender.stdout.threshold=ERROR
>>
>> # Windows event log
>> log4j.appender.nteventlog=org.apache.log4j.nt.NTEventLogAppender
>> log4j.appender.nteventlog.source=Test source
>> log4j.appender.nteventlog.layout=org.apache.log4j.PatternLayout
>> log4j.appender.nteventlog.layout.ConversionPattern=Time:
>> %d{ISO8601}%n%nSeverity: %p%n%nThread: %t%n%n%m%n
>> log4j.appender.nteventlog.threshold=DEBUG
>>
>> *3. Start Karaf: "bin\karaf clean"*
>>
>> This should work.
>>
>> *4. Exit Karaf*
>>
>> *5. Change the root looger line to:*
>>
>> log4j.rootLogger=INFO, stdout, nteventlog
>>
>> *6. Start Karaf again*
>>
>> I get the following error:
>>
>> 2016-07-04 15:05:39,534 | ERROR | s4j.pax.logging) | configadmin
>>  | ?? | [org.osgi.service.log.LogService,
>> org.knopflerfish.service.log.LogService,
>> org.ops4j.pax.logging.PaxLoggingService,
>> org.osgi.service.cm.ManagedService, id=12,
>> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]: Unexpected
>> problem updating configuration org.ops4j.pax.logging
>> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in java.library.path
>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
>> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>> at java.lang.System.loadLibrary(System.java:1122)
>> at
>> org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> at java.lang.Class.newInstance(Class.java:442)
>> at
>> org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:336)
>> at
>> org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)
>> at
>> org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator.java:97)
>> at
>> org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:735)
>> at
>> org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:615)
>> at
>> org.apache.log4j.PropertyConfigurator.doConfigure(PropertyCo

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Bengt Rodehav]

A theory: Could one of the bundles installed by feature pax-jetty be using
log4j 2.x directly without using Pax-logging? If so, would it too try to
read the log4j configuration file? I guess it would fail to load the DLL
since it is probably not compatible with log4j 2.x.

Could this happen? If so, how can I find out which bundle?

/Bengt

2016-07-04 15:15 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:

> Back to the Karaf mailing list
>
> I can actually get this problem on a standard vanilla Karaf 4.0.5. It
> seems to be triggered when installing the feature pax-jetty.
>
> *1. Install standard Karaf 4.0.5*
>
> *2. Replace org.ops4j.pax.logging.cfg with the following:*
>
> log4j.rootLogger=INFO, stdout
>
> # CONSOLE appender
> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
> log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p |
> %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
> log4j.appender.stdout.threshold=ERROR
>
> # Windows event log
> log4j.appender.nteventlog=org.apache.log4j.nt.NTEventLogAppender
> log4j.appender.nteventlog.source=Test source
> log4j.appender.nteventlog.layout=org.apache.log4j.PatternLayout
> log4j.appender.nteventlog.layout.ConversionPattern=Time:
> %d{ISO8601}%n%nSeverity: %p%n%nThread: %t%n%n%m%n
> log4j.appender.nteventlog.threshold=DEBUG
>
> *3. Start Karaf: "bin\karaf clean"*
>
> This should work.
>
> *4. Exit Karaf*
>
> *5. Change the root looger line to:*
>
> log4j.rootLogger=INFO, stdout, nteventlog
>
> *6. Start Karaf again*
>
> I get the following error:
>
> 2016-07-04 15:05:39,534 | ERROR | s4j.pax.logging) | configadmin
>| ?? | [org.osgi.service.log.LogService,
> org.knopflerfish.service.log.LogService,
> org.ops4j.pax.logging.PaxLoggingService,
> org.osgi.service.cm.ManagedService, id=12,
> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]: Unexpected
> problem updating configuration org.ops4j.pax.logging
> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
> at java.lang.System.loadLibrary(System.java:1122)
> at
> org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at
> org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:336)
> at
> org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)
> at
> org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator.java:97)
> at
> org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:735)
> at
> org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:615)
> at
> org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:502)
> at
> org.apache.log4j.PaxLoggingConfigurator.doConfigure(PaxLoggingConfigurator.java:72)
> at
> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.updated(PaxLoggingServiceImpl.java:214)
> at
> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl$1ManagedPaxLoggingService.updated(PaxLoggingServiceImpl.java:362)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)
> at
> org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1753)
> at
> org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)
> at java.lang.Thread.run(Thread.java:745)
>
> This makes sense since I haven't provided the DLL yet.
>
> *7. Exit Karaf*
>
> *8. Put the file NTEventLogAppender.amd64.dll in KARAF_HOME/lib (I attach
> the file for 64 bit Windows)*
>
> *9. Start Karaf again*
>
&g

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Bengt Rodehav]

52)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1753)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_74]
ERROR: Bundle org.apache.karaf.features.core [9] Error starting
mvn:org.apache.karaf.features/org.apache.karaf.features.core/4.0.5
(org.osgi.framework.BundleException: Unable to resolve
org.apache.karaf.features.core [9](R 9.0): missing requirement
[org.apache.karaf.features.core [9](R 9.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.ops4j.pax.url.mvn)(version>=2.4.0)(!(version>=3.0.0)))
Unresolved requirements: [[org.apache.karaf.features.core [9](R 9.0)]
osgi.wiring.package;
(&(osgi.wiring.package=org.ops4j.pax.url.mvn)(version>=2.4.0)(!(version>=3.0.0)))])org.osgi.framework.BundleException:
Unable to resolve org.apache.karaf.features.core [9](R 9.0): missing
requirement [org.apache.karaf.features.core [9](R 9.0)]
osgi.wiring.package;
(&(osgi.wiring.package=org.ops4j.pax.url.mvn)(version>=2.4.0)(!(version>=3.0.0)))
Unresolved requirements: [[org.apache.karaf.features.core [9](R 9.0)]
osgi.wiring.package;
(&(osgi.wiring.package=org.ops4j.pax.url.mvn)(version>=2.4.0)(!(version>=3.0.0)))]
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2117)
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:745)

So, the DLL seems to be loaded and Pax-logging seems to work using
Pax-logging 1.8.1 but not using Pax-logging 1.8.5.

I will re-post this conversation to the OOPS4J mailing list.

/Bengt


















2016-07-01 8:55 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:

> OK - I guess I misunderstood this then.
>
> Looking in the POM's I now see that there are dependencies to both log4j
> 1.2.16 and log4j 2.x.
>
> I wonder then why the NTEventLogAppender can't be used in Karaf 4.0.5.
> For a while I thought it might be a java version problem. I now use Java 8
> instead of Java 7 like I did before. But even if I run Karaf 4.0.5 using
> Java 7 I still get the same problem.
>
> I will try to use Karaf 4.0.5 with Pax-logging 1.8.1 to see if it makes
> any difference. What is the best way to accomplish that?
>
> /Bengt
>
> 2016-06-30 16:54 GMT+02:00 Achim Nierbeck <bcanh...@googlemail.com>:
>
>> Hi Bengt,
>>
>> newer versions of Pax-Logging don't use log4j2 per default so this should
>> still work ...
>> the underlying impl is still log4j 1 unless someone changed it on a minor
>> version update ...
>>
>> regards, Achim
>>
>>
>> 2016-06-30 16:23 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>>
>>> Thanks JB,
>>>
>>> Tried it though and no diffference.
>>>
>>> When investigating this it seems like newer versions of pax-logging uses
>>> log4j2. Unfortunately the NTEventLogAppender is incompatible with
>>> log4j2.
>>>
>>> I've found the project log4jna that seems to target this. Unfortunately
>>> I cannot find a released version that supports log4j2.
>>>
>>> Anyone else encountered this?
>>>
>>> /Bengt
>>>
>>> 2016-06-30 14:48 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>>>
>>>> In Karaf 4, the dll should go in lib/ext.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 06/30/2016 02:16 PM, Bengt Rodehav wrote:
>>>>
>>>>> I have a feeling that I need to put the NTEventLogAppender.amd4.dll in
>>>>> another directory in Karaf 4.0.5 then in Karaf 2.4.1.
>>>>>
>>>>> I have always put it in the directory %KARAF_HOME%/lib which works for
>>>>> Karaf 2.4.1. Where should DLL's be put in Karaf 4.0.5?
>>>>>
>>>>> /Bengt
>>>>>
>>>>> 2016-06-29 17:37 GMT+02:00 Bengt Rodehav <be...@rodehav.com
>>>>> <mailto:be...@rodehav.com>>:
>>>>>
>>>>>
>>>>> I'm trying to upgrade from Karaf 2..1 to

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Bengt Rodehav]

OK - I guess I misunderstood this then.

Looking in the POM's I now see that there are dependencies to both log4j
1.2.16 and log4j 2.x.

I wonder then why the NTEventLogAppender can't be used in Karaf 4.0.5. For
a while I thought it might be a java version problem. I now use Java 8
instead of Java 7 like I did before. But even if I run Karaf 4.0.5 using
Java 7 I still get the same problem.

I will try to use Karaf 4.0.5 with Pax-logging 1.8.1 to see if it makes any
difference. What is the best way to accomplish that?

/Bengt

2016-06-30 16:54 GMT+02:00 Achim Nierbeck <bcanh...@googlemail.com>:

> Hi Bengt,
>
> newer versions of Pax-Logging don't use log4j2 per default so this should
> still work ...
> the underlying impl is still log4j 1 unless someone changed it on a minor
> version update ...
>
> regards, Achim
>
>
> 2016-06-30 16:23 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:
>
>> Thanks JB,
>>
>> Tried it though and no diffference.
>>
>> When investigating this it seems like newer versions of pax-logging uses
>> log4j2. Unfortunately the NTEventLogAppender is incompatible with log4j2.
>>
>> I've found the project log4jna that seems to target this. Unfortunately I
>> cannot find a released version that supports log4j2.
>>
>> Anyone else encountered this?
>>
>> /Bengt
>>
>> 2016-06-30 14:48 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>>
>>> In Karaf 4, the dll should go in lib/ext.
>>>
>>> Regards
>>> JB
>>>
>>> On 06/30/2016 02:16 PM, Bengt Rodehav wrote:
>>>
>>>> I have a feeling that I need to put the NTEventLogAppender.amd4.dll in
>>>> another directory in Karaf 4.0.5 then in Karaf 2.4.1.
>>>>
>>>> I have always put it in the directory %KARAF_HOME%/lib which works for
>>>> Karaf 2.4.1. Where should DLL's be put in Karaf 4.0.5?
>>>>
>>>> /Bengt
>>>>
>>>> 2016-06-29 17:37 GMT+02:00 Bengt Rodehav <be...@rodehav.com
>>>> <mailto:be...@rodehav.com>>:
>>>>
>>>>
>>>> I'm trying to upgrade from Karaf 2..1 to 4.0.5 and I run into
>>>> problems regarding NTEventLogAppender. I get the following on
>>>> startup:
>>>>
>>>> 2016-06-29 17:16:05,354 | ERROR | 4j.pax.logging]) | configadmin
>>>>   | ?
>>>>  ? | [org.osgi.service.log.LogService,
>>>> org.knopflerfish.service.log.LogService,
>>>> org.ops4j.pax.logging.PaxLoggingService,
>>>> org.osgi.service.cm.ManagedService, id=34,
>>>> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]:
>>>> Unexpected problem updating configuration org.ops4j.pax.logging
>>>> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in
>>>> java.library.path
>>>>  at
>>>> java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)[:1.8.0_74]
>>>>  at
>>>> java.lang.Runtime.loadLibrary0(Runtime.java:870)[:1.8.0_74]
>>>>  at
>>>> java.lang.System.loadLibrary(System.java:1122)[:1.8.0_74]
>>>>  at
>>>>
>>>> org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
>>>>  at
>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>>> Method)[:1.8.0_74]
>>>>  at
>>>>
>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)[:1.8.0_74]
>>>>  at
>>>>
>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.8.0_74]
>>>>  at
>>>>
>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:423)[:1.8.0_74]
>>>>  at java.lang.Class.newInstance(Class.java:442)[:1.8.0_74]
>>>>  at
>>>>
>>>> org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:336)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>>>  at
>>>>
>>>> org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>>>  at
>>>>
>>>> org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Achim Nierbeck]

Hi Bengt,

newer versions of Pax-Logging don't use log4j2 per default so this should
still work ...
the underlying impl is still log4j 1 unless someone changed it on a minor
version update ...

regards, Achim


2016-06-30 16:23 GMT+02:00 Bengt Rodehav <be...@rodehav.com>:

> Thanks JB,
>
> Tried it though and no diffference.
>
> When investigating this it seems like newer versions of pax-logging uses
> log4j2. Unfortunately the NTEventLogAppender is incompatible with log4j2.
>
> I've found the project log4jna that seems to target this. Unfortunately I
> cannot find a released version that supports log4j2.
>
> Anyone else encountered this?
>
> /Bengt
>
> 2016-06-30 14:48 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>
>> In Karaf 4, the dll should go in lib/ext.
>>
>> Regards
>> JB
>>
>> On 06/30/2016 02:16 PM, Bengt Rodehav wrote:
>>
>>> I have a feeling that I need to put the NTEventLogAppender.amd4.dll in
>>> another directory in Karaf 4.0.5 then in Karaf 2.4.1.
>>>
>>> I have always put it in the directory %KARAF_HOME%/lib which works for
>>> Karaf 2.4.1. Where should DLL's be put in Karaf 4.0.5?
>>>
>>> /Bengt
>>>
>>> 2016-06-29 17:37 GMT+02:00 Bengt Rodehav <be...@rodehav.com
>>> <mailto:be...@rodehav.com>>:
>>>
>>>
>>> I'm trying to upgrade from Karaf 2..1 to 4.0.5 and I run into
>>> problems regarding NTEventLogAppender. I get the following on
>>> startup:
>>>
>>> 2016-06-29 17:16:05,354 | ERROR | 4j.pax.logging]) | configadmin
>>>   | ?
>>>  ? | [org.osgi.service.log.LogService,
>>> org.knopflerfish.service.log.LogService,
>>> org.ops4j.pax.logging.PaxLoggingService,
>>> org.osgi.service.cm.ManagedService, id=34,
>>> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]:
>>> Unexpected problem updating configuration org.ops4j.pax.logging
>>> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in
>>> java.library.path
>>>  at
>>> java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)[:1.8.0_74]
>>>  at
>>> java.lang.Runtime.loadLibrary0(Runtime.java:870)[:1.8.0_74]
>>>  at java.lang.System.loadLibrary(System.java:1122)[:1.8.0_74]
>>>  at
>>>
>>> org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
>>>  at
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>> Method)[:1.8.0_74]
>>>  at
>>>
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)[:1.8.0_74]
>>>  at
>>>
>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.8.0_74]
>>>  at
>>>
>>> java.lang.reflect.Constructor.newInstance(Constructor.java:423)[:1.8.0_74]
>>>  at java.lang.Class.newInstance(Class.java:442)[:1.8.0_74]
>>>  at
>>>
>>> org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:336)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>>  at
>>>
>>> org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>>  at
>>>
>>> org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator.java:97)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>>  at
>>>
>>> org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:735)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>>  at
>>>
>>> org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:639)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>>  at
>>>
>>> org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:504)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>>  at
>>>
>>> org.apache.log4j.PaxLoggingConfigurator.doConfigure(PaxLoggingConfigurator.java:72)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>>  at
>>>
>>> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.updated(PaxLoggingServiceImpl.java:214)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>>

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Bengt Rodehav]

Thanks JB,

Tried it though and no diffference.

When investigating this it seems like newer versions of pax-logging uses
log4j2. Unfortunately the NTEventLogAppender is incompatible with log4j2.

I've found the project log4jna that seems to target this. Unfortunately I
cannot find a released version that supports log4j2.

Anyone else encountered this?

/Bengt

2016-06-30 14:48 GMT+02:00 Jean-Baptiste Onofré :

> In Karaf 4, the dll should go in lib/ext.
>
> Regards
> JB
>
> On 06/30/2016 02:16 PM, Bengt Rodehav wrote:
>
>> I have a feeling that I need to put the NTEventLogAppender.amd4.dll in
>> another directory in Karaf 4.0.5 then in Karaf 2.4.1.
>>
>> I have always put it in the directory %KARAF_HOME%/lib which works for
>> Karaf 2.4.1. Where should DLL's be put in Karaf 4.0.5?
>>
>> /Bengt
>>
>> 2016-06-29 17:37 GMT+02:00 Bengt Rodehav > >:
>>
>>
>> I'm trying to upgrade from Karaf 2..1 to 4.0.5 and I run into
>> problems regarding NTEventLogAppender. I get the following on startup:
>>
>> 2016-06-29 17:16:05,354 | ERROR | 4j.pax.logging]) | configadmin
>>   | ?
>>  ? | [org.osgi.service.log.LogService,
>> org.knopflerfish.service.log.LogService,
>> org.ops4j.pax.logging.PaxLoggingService,
>> org.osgi.service.cm.ManagedService, id=34,
>> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]:
>> Unexpected problem updating configuration org.ops4j.pax.logging
>> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in
>> java.library.path
>>  at
>> java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)[:1.8.0_74]
>>  at
>> java.lang.Runtime.loadLibrary0(Runtime.java:870)[:1.8.0_74]
>>  at java.lang.System.loadLibrary(System.java:1122)[:1.8.0_74]
>>  at
>>
>> org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
>>  at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)[:1.8.0_74]
>>  at
>>
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)[:1.8.0_74]
>>  at
>>
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.8.0_74]
>>  at
>>
>> java.lang.reflect.Constructor.newInstance(Constructor.java:423)[:1.8.0_74]
>>  at java.lang.Class.newInstance(Class.java:442)[:1.8.0_74]
>>  at
>>
>> org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:336)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>  at
>>
>> org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>  at
>>
>> org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator.java:97)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>  at
>>
>> org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:735)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>  at
>>
>> org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:639)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>  at
>>
>> org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:504)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>  at
>>
>> org.apache.log4j.PaxLoggingConfigurator.doConfigure(PaxLoggingConfigurator.java:72)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>  at
>>
>> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.updated(PaxLoggingServiceImpl.java:214)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>  at
>>
>> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl$1ManagedPaxLoggingService.updated(PaxLoggingServiceImpl.java:362)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
>>  at
>>
>> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[7:org.apache.felix.configadmin:1.8.8]
>>  at
>>
>> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[7:org.apache.felix.configadmin:1.8.8]
>>  at
>>
>> org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.8]
>>  at
>>
>> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1444)[7:org.apache.felix.configadmin:1.8.8]
>>  at
>>
>> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1400)[7:org.apache.felix.configadmin:1.8.8]
>>  at
>>
>> org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8]
>>  at
>>
>> 

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Jean-Baptiste Onofré]

In Karaf 4, the dll should go in lib/ext.

Regards
JB

On 06/30/2016 02:16 PM, Bengt Rodehav wrote:

I have a feeling that I need to put the NTEventLogAppender.amd4.dll in
another directory in Karaf 4.0.5 then in Karaf 2.4.1.

I have always put it in the directory %KARAF_HOME%/lib which works for
Karaf 2.4.1. Where should DLL's be put in Karaf 4.0.5?

/Bengt

2016-06-29 17:37 GMT+02:00 Bengt Rodehav >:

I'm trying to upgrade from Karaf 2..1 to 4.0.5 and I run into
problems regarding NTEventLogAppender. I get the following on startup:

2016-06-29 17:16:05,354 | ERROR | 4j.pax.logging]) | configadmin
  | ?
 ? | [org.osgi.service.log.LogService,
org.knopflerfish.service.log.LogService,
org.ops4j.pax.logging.PaxLoggingService,
org.osgi.service.cm.ManagedService, id=34,
bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]:
Unexpected problem updating configuration org.ops4j.pax.logging
java.lang.UnsatisfiedLinkError: no NTEventLogAppender in
java.library.path
 at
java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)[:1.8.0_74]
 at java.lang.Runtime.loadLibrary0(Runtime.java:870)[:1.8.0_74]
 at java.lang.System.loadLibrary(System.java:1122)[:1.8.0_74]
 at
org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
 at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)[:1.8.0_74]
 at

sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)[:1.8.0_74]
 at

sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.8.0_74]
 at
java.lang.reflect.Constructor.newInstance(Constructor.java:423)[:1.8.0_74]
 at java.lang.Class.newInstance(Class.java:442)[:1.8.0_74]
 at

org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:336)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
 at

org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
 at

org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator.java:97)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
 at

org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:735)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
 at

org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:639)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
 at

org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:504)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
 at

org.apache.log4j.PaxLoggingConfigurator.doConfigure(PaxLoggingConfigurator.java:72)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
 at

org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.updated(PaxLoggingServiceImpl.java:214)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
 at

org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl$1ManagedPaxLoggingService.updated(PaxLoggingServiceImpl.java:362)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
 at

org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[7:org.apache.felix.configadmin:1.8.8]
 at

org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[7:org.apache.felix.configadmin:1.8.8]
 at

org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.8]
 at

org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1444)[7:org.apache.felix.configadmin:1.8.8]
 at

org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1400)[7:org.apache.felix.configadmin:1.8.8]
 at

org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8]
 at

org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8]
 at java.lang.Thread.run(Thread.java:745)[:1.8.0_74]

Like I did on Karaf 2.4.1, I have put the
file NTEventLogAppender.amd64.dll in the "lib" directory under
Karaf. It has the version 1.2.16.1.

Does anyone know how to get the NTEventLogAppender to work with
Karaf 4.0.5?

/Bengt







--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Bengt Rodehav]

I have a feeling that I need to put the NTEventLogAppender.amd4.dll in
another directory in Karaf 4.0.5 then in Karaf 2.4.1.

I have always put it in the directory %KARAF_HOME%/lib which works for
Karaf 2.4.1. Where should DLL's be put in Karaf 4.0.5?

/Bengt

2016-06-29 17:37 GMT+02:00 Bengt Rodehav :

> I'm trying to upgrade from Karaf 2..1 to 4.0.5 and I run into problems
> regarding NTEventLogAppender. I get the following on startup:
>
> 2016-06-29 17:16:05,354 | ERROR | 4j.pax.logging]) | configadmin
>| ?
> ? | [org.osgi.service.log.LogService,
> org.knopflerfish.service.log.LogService,
> org.ops4j.pax.logging.PaxLoggingService,
> org.osgi.service.cm.ManagedService, id=34,
> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]: Unexpected
> problem updating configuration org.ops4j.pax.logging
> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in java.library.path
> at
> java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)[:1.8.0_74]
> at java.lang.Runtime.loadLibrary0(Runtime.java:870)[:1.8.0_74]
> at java.lang.System.loadLibrary(System.java:1122)[:1.8.0_74]
> at
> org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)[:1.8.0_74]
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)[:1.8.0_74]
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.8.0_74]
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)[:1.8.0_74]
> at java.lang.Class.newInstance(Class.java:442)[:1.8.0_74]
> at
> org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:336)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
> at
> org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
> at
> org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator.java:97)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
> at
> org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:735)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
> at
> org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:639)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
> at
> org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:504)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
> at
> org.apache.log4j.PaxLoggingConfigurator.doConfigure(PaxLoggingConfigurator.java:72)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
> at
> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.updated(PaxLoggingServiceImpl.java:214)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
> at
> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl$1ManagedPaxLoggingService.updated(PaxLoggingServiceImpl.java:362)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[7:org.apache.felix.configadmin:1.8.8]
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[7:org.apache.felix.configadmin:1.8.8]
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.8]
> at
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1444)[7:org.apache.felix.configadmin:1.8.8]
> at
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1400)[7:org.apache.felix.configadmin:1.8.8]
> at
> org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8]
> at
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_74]
>
> Like I did on Karaf 2.4.1, I have put the
> file NTEventLogAppender.amd64.dll in the "lib" directory under Karaf. It
> has the version 1.2.16.1.
>
> Does anyone know how to get the NTEventLogAppender to work with Karaf
> 4.0.5?
>
> /Bengt
>
>
>
>
>

Log4j NTEventLogAppender in Karaf 4.0.5

[Bengt Rodehav]

I'm trying to upgrade from Karaf 2..1 to 4.0.5 and I run into problems
regarding NTEventLogAppender. I get the following on startup:

2016-06-29 17:16:05,354 | ERROR | 4j.pax.logging]) | configadmin
   | ?
? | [org.osgi.service.log.LogService,
org.knopflerfish.service.log.LogService,
org.ops4j.pax.logging.PaxLoggingService,
org.osgi.service.cm.ManagedService, id=34,
bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]: Unexpected
problem updating configuration org.ops4j.pax.logging
java.lang.UnsatisfiedLinkError: no NTEventLogAppender in java.library.path
at
java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)[:1.8.0_74]
at java.lang.Runtime.loadLibrary0(Runtime.java:870)[:1.8.0_74]
at java.lang.System.loadLibrary(System.java:1122)[:1.8.0_74]
at
org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)[:1.8.0_74]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)[:1.8.0_74]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.8.0_74]
at
java.lang.reflect.Constructor.newInstance(Constructor.java:423)[:1.8.0_74]
at java.lang.Class.newInstance(Class.java:442)[:1.8.0_74]
at
org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:336)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
at
org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
at
org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator.java:97)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
at
org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:735)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
at
org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:639)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
at
org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:504)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
at
org.apache.log4j.PaxLoggingConfigurator.doConfigure(PaxLoggingConfigurator.java:72)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
at
org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.updated(PaxLoggingServiceImpl.java:214)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
at
org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl$1ManagedPaxLoggingService.updated(PaxLoggingServiceImpl.java:362)[6:org.ops4j.pax.logging.pax-logging-service:1.8.5]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1444)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1400)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8]
at
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_74]

Like I did on Karaf 2.4.1, I have put the file NTEventLogAppender.amd64.dll
in the "lib" directory under Karaf. It has the version 1.2.16.1.

Does anyone know how to get the NTEventLogAppender to work with Karaf 4.0.5?

/Bengt

Re: Consider adding GELF Log4J 2 appender in Karaf 4.1.x by default

[Владимир Коньков]

Hi JB,

After adoption one of log4j2 GELF appenders I’ve share results with example 
configuration. Installation process of custom appender in general already 
properly documented in section «Custom appenders» of User Guide. 

Configuration example for gelfj appender for current Karaf (log4j 1.x) releases:

1. Install bundle in any way:

mvn:org.graylog2/gelfj/1.1.14

2. Modify config file org.ops4j.pax.logging.cfg by adding section:

# Async wrapper for send queue in case of GELF destination is unavailable
log4j.appender.gelfasync=org.apache.log4j.AsyncAppender
log4j.appender.gelfasync.blocking=false
log4j.appender.gelfasync.bufferSize=2
log4j.appender.gelfasync.appenders=gelf

# Define the GELF destination
log4j.appender.gelf=org.graylog2.log.GelfAppender
log4j.appender.gelf.graylogHost=tcp:
log4j.appender.gelf.graylogPort=
log4j.appender.gelf.facility=karaf
log4j.appender.gelf.layout=org.apache.log4j.PatternLayout
log4j.appender.gelf.extractStacktrace=true
log4j.appender.gelf.addExtendedInformation=true
log4j.appender.gelf.includeLocation=false
log4j.appender.gelf.additionalFields={'environment': 'QA'}

3. Modify config file org.ops4j.pax.logging.cfg by adding appender ‘gelfasync’ 
to global appenders list. Example:

log4j.rootLogger=INFO, out, osgi:*, gelfasync


Regards,
Vladimir Konkov
CIT Consulting LLC

> 20 марта 2016 г., в 10:56, Jean-Baptiste Onofré <j...@nanthrax.net> 
> написал(а):
> 
> Hi Valdimir,
> 
> by feature, I meant "a simple way" to provide/add it (not necessary a Karaf 
> feature) ;)
> 
> Probably the easier way now is to document how to do it in the dev guide with 
> an associated sample.
> 
> Regards
> JB
> 
> On 03/19/2016 03:03 PM, Владимир Коньков wrote:
>> Hi Jean-Baptiste!
>> 
>> We actively use GELF for streaming logs from Karaf based platforms for
>> years. But we stop building custom distributions at beginning of
>> adoption because of we use use different distrs from different vendors
>> (FuseSource, Talend, stock Servicemix, plain Karaf etc). Not all distrs
>> can be modified. It all needs to be upgradable.
>> Custom distribution is not practical way for us. Now we install appender
>> at deployment time by help of deployment automation tools like Ansible,
>> Puppet.
>> 
>> Current appender we use is GELFJ. Not so robust as I want but with some
>> infrastructure support it works:
>> 
>> https://github.com/t0xa/gelfj
>> 
>> It is already has OSGI headers to be fragment bundle for Pax-Logging.
>> 
>> For log4j2 I currently testing this 2 implementations:
>> 
>> 1. https://github.com/Graylog2/log4j2-gelf
>> 
>> 2. https://github.com/mp911de/logstash-gelf
>> 
>> For fist I’ve made couple of changes + OSGI headers for both. If someone
>> is interested in I can share results after decision to be made with
>> small configuration example. As before, we not plan build custom distrs.
>> 
>> I think Karaf feature is not to be needed because there is only one
>> proper way to package appender - one superbundle, fragment for
>> Pax-Logging without any exports and imports. Because of that -
>> installation of appender it is simple bundle installation and Karaf
>> restart. Or startup.properties modification, etc…
>> 
>> Regards,
>> Vladimir Konkov
>> CIT Consulting LLC
>> 
>>> 17 марта 2016 г., в 22:17, Jean-Baptiste Onofré <j...@nanthrax.net
>>> <mailto:j...@nanthrax.net <mailto:j...@nanthrax.net>>> написал(а):
>>> 
>>> Hi Vladimir
>>> 
>>> anyway, do you already have GELF in your custom distribution ?
>>> If so, I would love to document it for other potential users, or even
>>> propose an optional feature to add this.
>>> 
>>> WDYT ?
>>> 
>>> Regards
>>> JB
>>> 
>>> On 03/17/2016 06:33 AM, Владимир Коньков wrote:
>>>> Hi there!
>>>> 
>>>> Lukasz, Jean-Baptiste, thanx for reply. Actually your opinion is
>>>> expected and reasonable.
>>>> 
>>>> Lukasz, couple of comments:
>>>> 
>>>> Proposed solution is not specific for any tool - GELF is very common
>>>> format for app log streaming and it’s popularity is growing.
>>>> 
>>>> About custom distribution:
>>>> Usually, ops team is orthogonal to dev team. Infrastructure services
>>>> like logging provided by ops team, deployment platform stated by dev
>>>> team. It’s not comfortable to require custom version of Karaf from
>>>> dev team. Moreover it is not always possible. In our projects we
>>>> support m

Re: Consider adding GELF Log4J 2 appender in Karaf 4.1.x by default

[Jean-Baptiste Onofré]

Hi,

I agree with Lukasz: I have no problem to document and improve the way 
to include such appender in custom distribution, but I don't think it's 
a good idea to have it shipped by default.


I could also be a Decanter new collector/appender (as we already have a 
log collector/appender).


Regards
JB

On 03/16/2016 05:38 PM, Łukasz Dywicki wrote:

Hey Vladimir,
While I see reasoning to have this feature, I must say it is not a core
requirement to all users. If we would decide to have such appender we
easily can run into situation that everyone will want to have it’s own
appender and it’s dependencies installed/available by default in Karaf.
Sadly (in my perception) we can’t agree for that. If you would like to
push this forward please answer to this mail and send reply to
d...@karaf.apache.org <mailto:d...@karaf.apache.org> so we could continue
there. We need to keep in mind, that logging is part of foundation
functionalities offered in Karaf available in same shape under minimal
distribution.

What I can recommend you is custom (re)packaging of Karaf. This will
avoid troubles with manual modifications in configuration files and can
be fully automated with maven tooling we offer. All you need to do is
proper feature definition which will cause generation of
startup.properties. You can also override default configuration files
(ie. org.ops4j.pax.logging.cfg). In this way you will be able to produce
Karaf assembly right for you, your clients and colleagues.

Kind regards,
Lukasz
—
Apache Karaf Committer & PMC
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org



Wiadomość napisana przez Владимир Коньков <vkon...@citc.ru
<mailto:vkon...@citc.ru>> w dniu 16 mar 2016, o godz. 11:32:

Hi

As of version 4.1 Karaf will use Log4J 2 as logging backend (thanx,
Guillaume). It’s very good news, because it greatly simplify
configuration of robust production logging - compression, flexible
rotation rules, async, fallback logging. All this features comes out
of the box with Log4J 2. No more custom appenders needs to be
installed at first start time to achieve basic production quality
configuration.

But for advanced production logging one option is missing out of the
box - logging analysis tools integration, line ELK, Fluentd, Graylog,
Splunk. To achieve this capability in robust way we should again
install custom appender ( like https://github.com/Graylog2/log4j2-gelf
) at first start time.

I know, it can be installed as regular bundle fragment after first
startup. But installing appender this way has some drawbacks that make
it unacceptable for production usage:
1. First startup logs not coming in appender installed after start.
(stopper for automated deployments)
2. If appender configured before bundle cache initialization - there
is errors in file logs about missing appender class. Cache clean up is
not so rare on production deployment, usually it is simpler to clean
cache before some major software update that dealing with deps
conflicts on upgrade.
3. After installation of custom appender bundle host bundle should be
refreshed (some log entries may be lost).

If custom appender is MAIN logging channel restriction above not
acceptable for us. Workaround is simple but very inconvenient to
support for different versions of Karaf:
 - add appender jar to system lib
 - modify startup.properties to incude appender bundle

My proposal: include GELF Log4J 2 appender in standart distribution.
In such way we provide log streaming capability to all major logging
analysis tools. Because of growing adoption of log analysis tools it
may be good addition to Karaf feature portfolio in addition to own
solution Decanter.

I can provide PR on Github with carefully repackaged appender lib that
not export anything to other bundles.

What do you think?

Thanx,
Vladimir Konkov





--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Consider adding GELF Log4J 2 appender in Karaf 4.1.x by default

[Jean-Baptiste Onofré]

Hi Valdimir,

by feature, I meant "a simple way" to provide/add it (not necessary a 
Karaf feature) ;)


Probably the easier way now is to document how to do it in the dev guide 
with an associated sample.


Regards
JB

On 03/19/2016 03:03 PM, Владимир Коньков wrote:

Hi Jean-Baptiste!

We actively use GELF for streaming logs from Karaf based platforms for
years. But we stop building custom distributions at beginning of
adoption because of we use use different distrs from different vendors
(FuseSource, Talend, stock Servicemix, plain Karaf etc). Not all distrs
can be modified. It all needs to be upgradable.
Custom distribution is not practical way for us. Now we install appender
at deployment time by help of deployment automation tools like Ansible,
Puppet.

Current appender we use is GELFJ. Not so robust as I want but with some
infrastructure support it works:

https://github.com/t0xa/gelfj

It is already has OSGI headers to be fragment bundle for Pax-Logging.

For log4j2 I currently testing this 2 implementations:

1. https://github.com/Graylog2/log4j2-gelf

2. https://github.com/mp911de/logstash-gelf

For fist I’ve made couple of changes + OSGI headers for both. If someone
is interested in I can share results after decision to be made with
small configuration example. As before, we not plan build custom distrs.

I think Karaf feature is not to be needed because there is only one
proper way to package appender - one superbundle, fragment for
Pax-Logging without any exports and imports. Because of that -
installation of appender it is simple bundle installation and Karaf
restart. Or startup.properties modification, etc…

Regards,
Vladimir Konkov
CIT Consulting LLC


17 марта 2016 г., в 22:17, Jean-Baptiste Onofré > написал(а):

Hi Vladimir

anyway, do you already have GELF in your custom distribution ?
If so, I would love to document it for other potential users, or even
propose an optional feature to add this.

WDYT ?

Regards
JB

On 03/17/2016 06:33 AM, Владимир Коньков wrote:

Hi there!

Lukasz, Jean-Baptiste, thanx for reply. Actually your opinion is
expected and reasonable.

Lukasz, couple of comments:

Proposed solution is not specific for any tool - GELF is very common
format for app log streaming and it’s popularity is growing.

About custom distribution:
Usually, ops team is orthogonal to dev team. Infrastructure services
like logging provided by ops team, deployment platform stated by dev
team. It’s not comfortable to require custom version of Karaf from
dev team. Moreover it is not always possible. In our projects we
support many Karaf versions and distribution from Apache Servicemix
4.4 (Karaf 2.2.x) to TalendESB 5.x to modern Karaf 4.0.x - it is far
from always possible to build custom distr. But on all of this distrs
we use one set of custom appenders (!) for 4+ years. One of that
appenders finally die (compression, file rotation etc), but not other.

Lukasz is absolutely right - logging is part of foundation
functionalities and because of that it is hard to extend in
comparison to other parts. I’ve first voted for removing blueprint
from base distribution but ask you for common streaming log appender.

Anyway, thanx for Karaf - it is very good platform for any server
solutions on JVM. Of cause if you want and can adapt it.

Regards,
Vladimir Konkov



--
Jean-Baptiste Onofré
jbono...@apache.org 
http://blog.nanthrax.net
Talend - http://www.talend.com




--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Consider adding GELF Log4J 2 appender in Karaf 4.1.x by default

[Владимир Коньков]

Hi there!

Lukasz, Jean-Baptiste, thanx for reply. Actually your opinion is expected and 
reasonable. 

Lukasz, couple of comments:

Proposed solution is not specific for any tool - GELF is very common format for 
app log streaming and it’s popularity is growing. 

About custom distribution: 
Usually, ops team is orthogonal to dev team. Infrastructure services like 
logging provided by ops team, deployment platform stated by dev team. It’s not 
comfortable to require custom version of Karaf from dev team. Moreover it is 
not always possible. In our projects we support many Karaf versions and 
distribution from Apache Servicemix 4.4 (Karaf 2.2.x) to TalendESB 5.x to 
modern Karaf 4.0.x - it is far from always possible to build custom distr. But 
on all of this distrs we use one set of custom appenders (!) for 4+ years. One 
of that appenders finally die (compression, file rotation etc), but not other.

Lukasz is absolutely right - logging is part of foundation functionalities and 
because of that it is hard to extend in comparison to other parts. I’ve first 
voted for removing blueprint from base distribution but ask you for common 
streaming log appender.

Anyway, thanx for Karaf - it is very good platform for any server solutions on 
JVM. Of cause if you want and can adapt it.

Regards,
Vladimir Konkov

Re: Consider adding GELF Log4J 2 appender in Karaf 4.1.x by default

[Владимир Коньков]

Hi Jean-Baptiste!

We actively use GELF for streaming logs from Karaf based platforms for years. 
But we stop building custom distributions at beginning of adoption because of 
we use use different distrs from different vendors (FuseSource, Talend, stock 
Servicemix, plain Karaf etc). Not all distrs can be modified. It all needs to 
be upgradable. 
Custom distribution is not practical way for us. Now we install appender at 
deployment time by help of deployment automation tools like Ansible, Puppet.

Current appender we use is GELFJ. Not so robust as I want but with some 
infrastructure support it works:

https://github.com/t0xa/gelfj 

It is already has OSGI headers to be fragment bundle for Pax-Logging.

For log4j2 I currently testing this 2 implementations:

1. https://github.com/Graylog2/log4j2-gelf

2. https://github.com/mp911de/logstash-gelf 


For fist I’ve made couple of changes + OSGI headers for both. If someone is 
interested in I can share results after decision to be made with small 
configuration example. As before, we not plan build custom distrs.

I think Karaf feature is not to be needed because there is only one proper way 
to package appender - one superbundle, fragment for Pax-Logging without any 
exports and imports. Because of that - installation of appender it is simple 
bundle installation and Karaf restart. Or startup.properties modification, etc…

Regards,
Vladimir Konkov
CIT Consulting LLC

> 17 марта 2016 г., в 22:17, Jean-Baptiste Onofré  
> написал(а):
> 
> Hi Vladimir
> 
> anyway, do you already have GELF in your custom distribution ?
> If so, I would love to document it for other potential users, or even propose 
> an optional feature to add this.
> 
> WDYT ?
> 
> Regards
> JB
> 
> On 03/17/2016 06:33 AM, Владимир Коньков wrote:
>> Hi there!
>> 
>> Lukasz, Jean-Baptiste, thanx for reply. Actually your opinion is expected 
>> and reasonable.
>> 
>> Lukasz, couple of comments:
>> 
>> Proposed solution is not specific for any tool - GELF is very common format 
>> for app log streaming and it’s popularity is growing.
>> 
>> About custom distribution:
>> Usually, ops team is orthogonal to dev team. Infrastructure services like 
>> logging provided by ops team, deployment platform stated by dev team. It’s 
>> not comfortable to require custom version of Karaf from dev team. Moreover 
>> it is not always possible. In our projects we support many Karaf versions 
>> and distribution from Apache Servicemix 4.4 (Karaf 2.2.x) to TalendESB 5.x 
>> to modern Karaf 4.0.x - it is far from always possible to build custom 
>> distr. But on all of this distrs we use one set of custom appenders (!) for 
>> 4+ years. One of that appenders finally die (compression, file rotation 
>> etc), but not other.
>> 
>> Lukasz is absolutely right - logging is part of foundation functionalities 
>> and because of that it is hard to extend in comparison to other parts. I’ve 
>> first voted for removing blueprint from base distribution but ask you for 
>> common streaming log appender.
>> 
>> Anyway, thanx for Karaf - it is very good platform for any server solutions 
>> on JVM. Of cause if you want and can adapt it.
>> 
>> Regards,
>> Vladimir Konkov
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Consider adding GELF Log4J 2 appender in Karaf 4.1.x by default

[Łukasz Dywicki]

Hey Vladimir,
While I see reasoning to have this feature, I must say it is not a core 
requirement to all users. If we would decide to have such appender we easily 
can run into situation that everyone will want to have it’s own appender and 
it’s dependencies installed/available by default in Karaf. Sadly (in my 
perception) we can’t agree for that. If you would like to push this forward 
please answer to this mail and send reply to d...@karaf.apache.org 
<mailto:d...@karaf.apache.org> so we could continue there. We need to keep in 
mind, that logging is part of foundation functionalities offered in Karaf 
available in same shape under minimal distribution. 

What I can recommend you is custom (re)packaging of Karaf. This will avoid 
troubles with manual modifications in configuration files and can be fully 
automated with maven tooling we offer. All you need to do is proper feature 
definition which will cause generation of startup.properties. You can also 
override default configuration files (ie. org.ops4j.pax.logging.cfg). In this 
way you will be able to produce Karaf assembly right for you, your clients and 
colleagues. 

Kind regards,
Lukasz
—
Apache Karaf Committer & PMC
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org


> Wiadomość napisana przez Владимир Коньков <vkon...@citc.ru> w dniu 16 mar 
> 2016, o godz. 11:32:
> 
> Hi
> 
> As of version 4.1 Karaf will use Log4J 2 as logging backend (thanx, 
> Guillaume). It’s very good news, because it greatly simplify configuration of 
> robust production logging - compression, flexible rotation rules, async, 
> fallback logging. All this features comes out of the box with Log4J 2. No 
> more custom appenders needs to be installed at first start time to achieve 
> basic production quality configuration.
> 
> But for advanced production logging one option is missing out of the box - 
> logging analysis tools integration, line ELK, Fluentd, Graylog, Splunk. To 
> achieve this capability in robust way we should again install custom appender 
> ( like https://github.com/Graylog2/log4j2-gelf 
> <https://github.com/Graylog2/log4j2-gelf> ) at first start time.
> 
> I know, it can be installed as regular bundle fragment after first startup. 
> But installing appender this way has some drawbacks that make it unacceptable 
> for production usage:
> 1. First startup logs not coming in appender installed after start. (stopper 
> for automated deployments)
> 2. If appender configured before bundle cache initialization - there is 
> errors in file logs about missing appender class. Cache clean up is not so 
> rare on production deployment, usually it is simpler to clean cache before 
> some major software update that dealing with deps conflicts on upgrade.
> 3. After installation of custom appender bundle host bundle should be 
> refreshed (some log entries may be lost).
> 
> If custom appender is MAIN logging channel restriction above not acceptable 
> for us. Workaround is simple but very inconvenient to support for different 
> versions of Karaf:
>  - add appender jar to system lib
>  - modify startup.properties to incude appender bundle
> 
> My proposal: include GELF Log4J 2 appender in standart distribution. In such 
> way we provide log streaming capability to all major logging analysis tools. 
> Because of growing adoption of log analysis tools it may be good addition to 
> Karaf feature portfolio in addition to own solution Decanter.
> 
> I can provide PR on Github with carefully repackaged appender lib that not 
> export anything to other bundles.
> 
> What do you think?
> 
> Thanx,
> Vladimir Konkov
> 

Re: Consider adding GELF Log4J 2 appender in Karaf 4.1.x by default

[Jean-Baptiste Onofré]

Hi Vladimir

anyway, do you already have GELF in your custom distribution ?
If so, I would love to document it for other potential users, or even 
propose an optional feature to add this.


WDYT ?

Regards
JB

On 03/17/2016 06:33 AM, Владимир Коньков wrote:

Hi there!

Lukasz, Jean-Baptiste, thanx for reply. Actually your opinion is expected and 
reasonable.

Lukasz, couple of comments:

Proposed solution is not specific for any tool - GELF is very common format for 
app log streaming and it’s popularity is growing.

About custom distribution:
Usually, ops team is orthogonal to dev team. Infrastructure services like 
logging provided by ops team, deployment platform stated by dev team. It’s not 
comfortable to require custom version of Karaf from dev team. Moreover it is 
not always possible. In our projects we support many Karaf versions and 
distribution from Apache Servicemix 4.4 (Karaf 2.2.x) to TalendESB 5.x to 
modern Karaf 4.0.x - it is far from always possible to build custom distr. But 
on all of this distrs we use one set of custom appenders (!) for 4+ years. One 
of that appenders finally die (compression, file rotation etc), but not other.

Lukasz is absolutely right - logging is part of foundation functionalities and 
because of that it is hard to extend in comparison to other parts. I’ve first 
voted for removing blueprint from base distribution but ask you for common 
streaming log appender.

Anyway, thanx for Karaf - it is very good platform for any server solutions on 
JVM. Of cause if you want and can adapt it.

Regards,
Vladimir Konkov



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Consider adding GELF Log4J 2 appender in Karaf 4.1.x by default

[Владимир Коньков]

Hi

As of version 4.1 Karaf will use Log4J 2 as logging backend (thanx, Guillaume). 
It’s very good news, because it greatly simplify configuration of robust 
production logging - compression, flexible rotation rules, async, fallback 
logging. All this features comes out of the box with Log4J 2. No more custom 
appenders needs to be installed at first start time to achieve basic production 
quality configuration.

But for advanced production logging one option is missing out of the box - 
logging analysis tools integration, line ELK, Fluentd, Graylog, Splunk. To 
achieve this capability in robust way we should again install custom appender ( 
like https://github.com/Graylog2/log4j2-gelf 
<https://github.com/Graylog2/log4j2-gelf> ) at first start time.

I know, it can be installed as regular bundle fragment after first startup. But 
installing appender this way has some drawbacks that make it unacceptable for 
production usage:
1. First startup logs not coming in appender installed after start. (stopper 
for automated deployments)
2. If appender configured before bundle cache initialization - there is errors 
in file logs about missing appender class. Cache clean up is not so rare on 
production deployment, usually it is simpler to clean cache before some major 
software update that dealing with deps conflicts on upgrade.
3. After installation of custom appender bundle host bundle should be refreshed 
(some log entries may be lost).

If custom appender is MAIN logging channel restriction above not acceptable for 
us. Workaround is simple but very inconvenient to support for different 
versions of Karaf:
 - add appender jar to system lib
 - modify startup.properties to incude appender bundle

My proposal: include GELF Log4J 2 appender in standart distribution. In such 
way we provide log streaming capability to all major logging analysis tools. 
Because of growing adoption of log analysis tools it may be good addition to 
Karaf feature portfolio in addition to own solution Decanter.

I can provide PR on Github with carefully repackaged appender lib that not 
export anything to other bundles.

What do you think?

Thanx,
Vladimir Konkov

Using log4j json-event-layout with Karaf 3.0.5 running under servicemix

[D]

I am trying to use  JSONEventLayoutV1
<https://github.com/logstash/log4j-jsonevent-layout>   as the pattern layout
for karaf logging.

The steps that I have followed.

1. Modified the pom.xml file of jsonevent-layout as shown below:-


org.apache.felix
maven-bundle-plugin
2.3.7
true


${project.groupId}.${project.artifactId}
   
${project.groupId}.${project.artifactId}
!*
   
org.ops4j.pax.logging.pax-logging-service;bundle-version="[1.6,1.7)"
   
*;scope=compile|runtime;inline=true
${project.version}




2. Build json format using mvn clean install -Pbundle

3. Copy bundle created to system directory

mkdir -p
${karaf.home}/system/net/logstash/log4j/jsonevent-layout/1.8-SNAPSHOT/
cp target/jsonevent-layout-1.8-SNAPSHOT.jar
${karaf.home}/system/net/logstash/log4j/jsonevent-layout/1.8-SNAPSHOT/

4. Add this line to etc/startup.properties before Pax Logging
   
net/logstash/log4j/jsonevent-layout/1.8-SNAPSHOT/jsonevent-layout-1.8-SNAPSHOT.jar=3
mvn\:org.ops4j.pax.url/pax-url-aether/2.4.1 = 5
mvn\:org.ops4j.pax.url/pax-url-wrap/2.4.1/jar/uber = 5
mvn\:org.ops4j.pax.logging/pax-logging-api/1.8.4 = 8
mvn\:org.ops4j.pax.logging/pax-logging-service/1.8.4 = 8
Updated org.ops4j.pax.logging.cfg as follows:-
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=net.logstash.log4j.JSONEventLayoutV1
log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p |
%-16.16t | %-32.32c{1} | %X{bundle.id} - %X{bundle.name} -
%X{bundle.version} | %m%n

But whenever I am starting Karaf I am getting the below exception:-
jabong@jabong1143:~/Downloads/software/dev/apache-servicemix-6.1.0$ sudo
bin/servicemix
Please wait while Apache ServiceMix is starting...
 21% [===>   
]log4j:ERROR Could not instantiate class
[net.logstash.log4j.JSONEventLayoutV1].
java.lang.ClassNotFoundException: net.logstash.log4j.JSONEventLayoutV1 not
found by org.ops4j.pax.logging.pax-logging-service [5]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.apache.log4j.helpers.Loader.loadClass(Loader.java:198)
at
org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:326)
at
org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)
at
org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator.java:129)
at
org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:735)
at
org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:615)
at
org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:502)
at
org.apache.log4j.PaxLoggingConfigurator.doConfigure(PaxLoggingConfigurator.java:72)
at
org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.updated(PaxLoggingServiceImpl.java:214)
at
org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl$1ManagedPaxLoggingService.updated(PaxLoggingServiceImpl.java:362)
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)
at
org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1747)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
at java.lang.Thread.run(Thread.java:745)
log4j:ERROR No layout set for the appender named [out].
100%
[]

Can some one let me know what I am doing wrong? 





--
View this message in context: 
http://karaf.922171.n3.nabble.com/Using-log4j-json-event-layout-with-Karaf-3-0-5-running-under-servicemix-tp4045599.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Configuring location of log4j out files

[Martin Lichtin]

What I'm suggesting is to decouple the logfile location, as done with 
other kinds of locations such as:


${karaf.home}
${karaf.base}
${karaf.data}
${karaf.etc}

and introduce an additional ${karaf.log} ($KARAF_LOG)

Currently, ${karaf.data}/log (or $KARAF_DATA/log) occurs in several 
places:


./etc/org.ops4j.pax.logging.cfg
./bin/stop
./bin/start
./bin/status

With a KARAF_LOG, the location could be managed in one place (./bin/setenv).

On 11.03.2015 11:24, Achim Nierbeck wrote:

How about ${karaf.home}/log?

2015-03-11 11:00 GMT+01:00 Martin Lichtin lich...@yahoo.com 
mailto:lich...@yahoo.com:


I was wondering about supporting configuring a specific location
for the Karaf log files.
There are use cases where these files must not be kept under the
data directory.
Could it be supported by use of a ${karaf.log} which defaults to
${karaf.data}/log ?




--

Apache Member
Apache Karaf http://karaf.apache.org/ Committer  PMC
OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ 
Committer  Project Lead

blog http://notizblog.nierbeck.de/
Co-Author of Apache Karaf Cookbook http://bit.ly/1ps9rkS

Software Architect / Project Manager / Scrum Master

Configuring location of log4j out files

[Martin Lichtin]

I was wondering about supporting configuring a specific location for the Karaf 
log files.
There are use cases where these files must not be kept under the data 
directory.
Could it be supported by use of a ${karaf.log} which defaults to 
${karaf.data}/log ?

Re: Configuring location of log4j out files

[Achim Nierbeck]

How about ${karaf.home}/log?

2015-03-11 11:00 GMT+01:00 Martin Lichtin lich...@yahoo.com:

 I was wondering about supporting configuring a specific location for the
 Karaf log files.
 There are use cases where these files must not be kept under the data
 directory.
 Could it be supported by use of a ${karaf.log} which defaults to
 ${karaf.data}/log ?




-- 

Apache Member
Apache Karaf http://karaf.apache.org/ Committer  PMC
OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer 
Project Lead
blog http://notizblog.nierbeck.de/
Co-Author of Apache Karaf Cookbook http://bit.ly/1ps9rkS

Software Architect / Project Manager / Scrum Master

Re: Enabling Flume log4j appender logging in Karaf

[syedbahm]

The fragment seems to show as resolved -- so if it is working we should 
have seen it connecting to the hostname specified in the appender 
configuration -- which is not happening. How can I find out if its 
reaching the point of instantiating the appender specified class and 
actually trying to append any log.


Details:

bundle:list or la
shows that the fragment host is resolved.
---
 7 | Resolved |   7 | 1.0.0.SNAPSHOT | Flume NG Log4j Appender, 
Hosts: 9

 8 | Active   |   8 | 1.7.2  | OPS4J Pax Logging - API
 9 | Active   |   8 | 1.7.2  | OPS4J Pax Logging - 
Service, Fragments: 76, 7

---

opendaylight-user@rootbundle:info 9

OPS4J Pax Logging - Service (9)
---
opendaylight-user@rootbundle:refresh 9
Error executing command: Access to system bundle 9 denied. You can 
override with -f

opendaylight-user@rootbundle:refresh -f 9
opendaylight-user@rootbundle:info 9

OPS4J Pax Logging - Service (9)
---
opendaylight-user@rootbundle:refresh -f 7
opendaylight-user@rootbundle:info 7

Flume NG Log4j Appender (7)
---
opendaylight-user@rootbundle:info 7

Flume NG Log4j Appender (7)
---
opendaylight-user@root



On 10/20/2014 10:38 PM, Achim Nierbeck wrote:


Hi
Is the fragment bundle attached to the host bundle. You can tell by 
listing all bundles with la. The fragment bundle should be in resolved 
state.
If you do a bundle: info on the host or fragment it should also tell 
you if the fragment is attached.

If not try a refresh on the host bundle.

Regards, Achim

sent from mobile device

Am 20.10.2014 23:20 schrieb syedbahm syedb...@cisco.com 
mailto:syedb...@cisco.com:


Forgot to mention
   Please let me know what knobs can I turn on to further debug
this thing.
I tried remote debugging karaf with flume4jappender it looks like the
appender class is not called out at all. How can I further debug whats
happenning?



--
View this message in context:

http://karaf.922171.n3.nabble.com/Enabling-Flume-log4j-appender-logging-in-Karaf-tp4036033p4036035.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Enabling Flume log4j appender logging in Karaf

[Achim Nierbeck]

The good news,
Your setup is good as the list of bundles already shows the fragment bundle
to be attached to the right host bundle.
Does the appender require something special? Any certain classes from
log4j?
You could try to debug into the appender and try to see if it is actually
called. If not it's something in the configuration.

Regards, Achim

sent from mobile device
Am 21.10.2014 08:29 schrieb syedbahm syedb...@cisco.com:

  The fragment seems to show as resolved -- so if it is working we should
 have seen it connecting to the hostname specified in the appender
 configuration -- which is not happening. How can I find out if its reaching
 the point of instantiating the appender specified class and actually trying
 to append any log.

 Details:

 bundle:list or la
 shows that the fragment host is resolved.
 ---
  7 | Resolved |   7 | 1.0.0.SNAPSHOT | Flume NG Log4j Appender,
 Hosts: 9
  8 | Active   |   8 | 1.7.2  | OPS4J Pax Logging -
 API
  9 | Active   |   8 | 1.7.2  | OPS4J Pax Logging -
 Service, Fragments: 76, 7
 ---

 opendaylight-user@rootbundle:info 9

 OPS4J Pax Logging - Service (9)
 ---
 opendaylight-user@rootbundle:refresh 9
 Error executing command: Access to system bundle 9 denied. You can
 override with -f
 opendaylight-user@rootbundle:refresh -f 9
 opendaylight-user@rootbundle:info 9

 OPS4J Pax Logging - Service (9)
 ---
 opendaylight-user@rootbundle:refresh -f 7
 opendaylight-user@rootbundle:info 7

 Flume NG Log4j Appender (7)
 ---
 opendaylight-user@rootbundle:info 7

 Flume NG Log4j Appender (7)
 ---
 opendaylight-user@root



 On 10/20/2014 10:38 PM, Achim Nierbeck wrote:

 Hi
 Is the fragment bundle attached to the host bundle. You can tell by
 listing all bundles with la. The fragment bundle should be in resolved
 state.
 If you do a bundle: info on the host or fragment it should also tell you
 if the fragment is attached.
 If not try a refresh on the host bundle.

 Regards, Achim

 sent from mobile device
 Am 20.10.2014 23:20 schrieb syedbahm syedb...@cisco.com:

 Forgot to  mention
Please let me know what knobs can I turn on to further debug this
 thing.
 I tried remote debugging karaf with flume4jappender it looks like the
 appender class is not called out at all. How can I further debug whats
 happenning?



 --
 View this message in context:
 http://karaf.922171.n3.nabble.com/Enabling-Flume-log4j-appender-logging-in-Karaf-tp4036033p4036035.html
 Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Enabling Flume log4j appender logging in Karaf

[syedbahm]

I tried remote debugging by putting karaf in debug + suspend mode and 
connect from the other end running log4j flume appender code. The log4j 
flume Appender class configured in org.ops4j.pax.logging.cfg as shown 
below doesn't get called.


---
# Root logger
log4j.rootLogger = DEBUG, out, flume, osgi:*

# flume appender
log4j.appender.flume=org.apache.flume.clients.log4jappender.Log4jAppender
log4j.appender.flume.Port=7070
log4j.appender.flume.Hostname=my lab setup ip
log4j.appender.flume.layout=org.apache.log4j.PatternLayout

-

When you mentioned it might be related to configuration -- can you 
further provide details about which config you are doubting ?


thx
-syed






On 10/20/2014 11:49 PM, Achim Nierbeck wrote:


The good news,
Your setup is good as the list of bundles already shows the fragment 
bundle to be attached to the right host bundle.
Does the appender require something special? Any certain classes from 
log4j?
You could try to debug into the appender and try to see if it is 
actually called. If not it's something in the configuration.


Regards, Achim

sent from mobile device

Am 21.10.2014 08:29 schrieb syedbahm syedb...@cisco.com 
mailto:syedb...@cisco.com:


The fragment seems to show as resolved -- so if it is working we
should have seen it connecting to the hostname specified in the
appender configuration -- which is not happening. How can I find
out if its reaching the point of instantiating the appender
specified class and actually trying to append any log.

Details:

bundle:list or la
shows that the fragment host is resolved.
---
 7 | Resolved |   7 | 1.0.0.SNAPSHOT | Flume NG Log4j
Appender, Hosts: 9
 8 | Active   |   8 | 1.7.2  | OPS4J Pax Logging -
API
 9 | Active   |   8 | 1.7.2  | OPS4J Pax Logging -
Service, Fragments: 76, 7
---

opendaylight-user@rootbundle:info 9

OPS4J Pax Logging - Service (9)
---
opendaylight-user@rootbundle:refresh 9
Error executing command: Access to system bundle 9 denied. You can
override with -f
opendaylight-user@rootbundle:refresh -f 9
opendaylight-user@rootbundle:info 9

OPS4J Pax Logging - Service (9)
---
opendaylight-user@rootbundle:refresh -f 7
opendaylight-user@rootbundle:info 7

Flume NG Log4j Appender (7)
---
opendaylight-user@rootbundle:info 7

Flume NG Log4j Appender (7)
---
opendaylight-user@root



On 10/20/2014 10:38 PM, Achim Nierbeck wrote:


Hi
Is the fragment bundle attached to the host bundle. You can tell
by listing all bundles with la. The fragment bundle should be in
resolved state.
If you do a bundle: info on the host or fragment it should also
tell you if the fragment is attached.
If not try a refresh on the host bundle.

Regards, Achim

sent from mobile device

Am 20.10.2014 23:20 schrieb syedbahm syedb...@cisco.com
mailto:syedb...@cisco.com:

Forgot to  mention
   Please let me know what knobs can I turn on to further
debug this thing.
I tried remote debugging karaf with flume4jappender it looks
like the
appender class is not called out at all. How can I further
debug whats
happenning?



--
View this message in context:

http://karaf.922171.n3.nabble.com/Enabling-Flume-log4j-appender-logging-in-Karaf-tp4036033p4036035.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Enabling Flume log4j appender logging in Karaf

[syedbahm]

Hi,
I have been trying unsuccessfully to have a karaf distribution connect 
to elastic search via flume using the FlumeLog4jAppender.


 I followed the steps listed here 
http://blog.nanthrax.net/2012/12/create-custom-log4j-appender-for-karaf-and-pax-logging/ 
for adding a custom appender and applied them to flume's source log4j 
appender module and the karaf logging service configuration files.  From 
karaf console I see that the flume-log4jappender module appears as 
resolved and see that the logging-service is in active state.


In the logs I see the following that doesn't give much information.. 
being new to Karaf not sure what to  make out of those messages.


---
 | 20 - org.apache.aries.blueprint.core - 1.4.0 | No blueprint 
application found in bundle org.ops4j.pax.logging.pax-logging-service
2014-10-20 11:37:11,305 | DEBUG | Event Dispatcher | 
BlueprintExtender| 20 - org.apache.aries.blueprint.core 
- 1.4.0 | Starting BlueprintContainer destruction process for bundle 
org.apache.flume.log4jappender
2014-10-20 11:37:11,305 | DEBUG | Event Dispatcher | 
BlueprintExtender| 20 - org.apache.aries.blueprint.core 
- 1.4.0 | Not a blueprint bundle or destruction of BlueprintContainer 
already finished for org.apache.flume.log4jappender.




Please see my detailed configuration below.
thx
-Syed



Here is how my modified flume log4j appender module pom.xml looks

-
1.

project xmlns=http://maven.apache.org/POM/4.0.0; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;

modelVersion4.0.0/modelVersion
parent
groupIdcom.company.one/groupId
artifactIdcommons.parent/artifactId
version1.0.0-SNAPSHOT/version
relativePath../../commons/parent/relativePath
/parent

  groupIdorg.apache.flume.flume-ng-clients/groupId
  artifactIdflume-ng-log4jappender/artifactId
  nameFlume NG Log4j Appender/name

build
plugins

plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version2.3.5/version
executions
execution
phasepackage/phase
goals
goalbundle/goal
/goals
/execution
/executions
extensionstrue/extensions
configuration
instructions
Export-Package
org.apache.flume.clients.log4jappender
/Export-Package
Import-Package/Import-Package
Fragment-Hostorg.ops4j.pax.logging.pax-logging-service/Fragment-Host
Bundle-SymbolicNameorg.apache.flume.log4jappender/Bundle-SymbolicName
_failoktrue/_failok
/instructions
/configuration
/plugin
/plugins
  /build
  dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.10/version
scopetest/scope
/dependency


dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.17/version
/dependency

dependency
groupIdlog4j/groupId
artifactIdapache-log4j-extras/artifactId
version1.1/version
/dependency
dependency
groupIdorg.apache.flume/groupId
artifactIdflume-ng-sdk/artifactId
version1.6.0-SNAPSHOT/version
/dependency

!-- pull in flume core only for unit tests. TODO: not ideal --
dependency
groupIdorg.apache.flume/groupId
artifactIdflume-ng-core/artifactId
version1.6.0-SNAPSHOT/version
scopetest/scope
/dependency

dependency
groupIdorg.apache.flume/groupId
artifactIdflume-ng-configuration/artifactId
version1.6.0-SNAPSHOT/version
scopetest/scope
/dependency

dependency
groupIdorg.ops4j.pax.logging/groupId
artifactIdpax-logging-service/artifactId
version1.7.2/version
/dependency


/dependencies

/project
--

2. I have placed the flume-ng-log4jappender-1.0.0-SNAPSHOT.jar in karaf 
sytem's folder and the path looks like this


system/org/apache/flume/flume-ng-clients/flume-ng-log4jappender/1.0.0-SNAPSHOT/

3. I have modified the /etc/startup.properties as

mvn\:org.ops4j.pax.url/pax-url-wrap/1.6.0 = 5
*mvn\:org.ops4j.pax.logging/pax-logging-api/1.7.2 = 8**
**mvn\:org.ops4j.pax.logging/pax-logging-service/1.7.2 = 8**
**mvn\:org.apache.flume.flume-ng-clients/flume-ng-log4jappender/1.0.0-SNAPSHOT 
= 8*


mvn\:org.apache.karaf.service/org.apache.karaf.service.guard/3.0.1 = 10
mvn\:org.apache.felix/org.apache.felix.configadmin/1.6.0 = 10
mvn\:org.apache.felix/org.apache.felix.fileinstall/3.2.8 = 11

4. I have modified the  etc/org.ops4j.pax.logging.cfg to include the 
flume appender as follows


# Root logger
log4j.rootLogger = DEBUG, out

Re: Enabling Flume log4j appender logging in Karaf

[syedbahm]

Forgot to  mention 
   Please let me know what knobs can I turn on to further debug this thing. 
I tried remote debugging karaf with flume4jappender it looks like the
appender class is not called out at all. How can I further debug whats
happenning?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Enabling-Flume-log4j-appender-logging-in-Karaf-tp4036033p4036035.html
Sent from the Karaf - User mailing list archive at Nabble.com.

No appenders could be found for logger (log4j related)

[asookazian2]

We are seeing the following message when deploying a WAR bundle and starting
karaf 3.0.1:

admin@NextGate () log4j:WARN No appenders could be found for logger
(org.springframework.web.servlet.DispatcherServlet).
log4j:WARN Please initialize the log4j system properly.

I was told to remove log4j and use 'mvn dependency:tree' to determine how
the transitive dependency is happening:

i executed the following cmd: mvn dependency:tree -Dverbose -Dincludes=log4j
10:28 [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @
RelationManager-OSGi ---
[INFO]
com.nextgate.mm.relation.deploys:RelationManager-OSGi:war:1.0.0-SNAPSHOT
[INFO] +- org.slf4j:slf4j-log4j12:jar:1.7.2:compile
[INFO] |  \- (log4j:log4j:jar:1.2.16:compile - version managed from 1.2.17;
omitted for duplicate)
[INFO] \- log4j:log4j:jar:1.2.16:compile

I tried to remove the log4j reference in the bundle-classpath for
maven-bundle-plugin config but starting seeing other exceptions
(ClassNotFoundExceptions for log4j classes).

This is what is relevant in the bundle-classpath for the maven-bundle-plugin
section in pom.xml for this WAR project.  I have tried removing
log4j-1.2.16.jar and slf4j-api-1.7.2.jar and see various exceptions in
karaf.log.

Bundle-ClassPath.
...
,WEB-INF/lib/log4j-1.2.16.jar
,WEB-INF/lib/slf4j-api-1.7.2.jar
,WEB-INF/lib/slf4j-log4j12-1.7.2.jar
...
/Bundle-ClassPath

Now I have finally resorted to including a log4j.xml file in the root of the
WAR so that log4j will find it in the classpath.  Now the WARN logging above
to the karaf console is gone but the logging for the file appender has a
different format than what is in the karaf.log.

Here is my current log4j.xml config.  I was thinking about using
./data/log/karaf.log and appending to that log instead of a test.log.

   
   appender name=FILE class=org.apache.log4j.RollingFileAppender
 
 
 
 
 

 layout class=org.apache.log4j.PatternLayout
   
 /layout  
   /appender

Am I missing something simple here (i.e. making this too complicated as a
solution)?  Any assistance is appreciated. thx.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: No appenders could be found for logger (log4j related)

[Achim Nierbeck]

If you want to use logging, you shouldn't contain those jars in your war
file.
Use Package-Import instead.
The Maven-Bundle-Plugin is your friend in helping to resolve those
dependencies.

regards, Achim


2014-08-13 17:33 GMT+02:00 asookazian2 asookaz...@gmail.com:

 We are seeing the following message when deploying a WAR bundle and
 starting
 karaf 3.0.1:

 admin@NextGate () log4j:WARN No appenders could be found for logger
 (org.springframework.web.servlet.DispatcherServlet).
 log4j:WARN Please initialize the log4j system properly.

 I was told to remove log4j and use 'mvn dependency:tree' to determine how
 the transitive dependency is happening:

 i executed the following cmd: mvn dependency:tree -Dverbose
 -Dincludes=log4j
 10:28 [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @
 RelationManager-OSGi ---
 [INFO]
 com.nextgate.mm.relation.deploys:RelationManager-OSGi:war:1.0.0-SNAPSHOT
 [INFO] +- org.slf4j:slf4j-log4j12:jar:1.7.2:compile
 [INFO] |  \- (log4j:log4j:jar:1.2.16:compile - version managed from 1.2.17;
 omitted for duplicate)
 [INFO] \- log4j:log4j:jar:1.2.16:compile

 I tried to remove the log4j reference in the bundle-classpath for
 maven-bundle-plugin config but starting seeing other exceptions
 (ClassNotFoundExceptions for log4j classes).

 This is what is relevant in the bundle-classpath for the
 maven-bundle-plugin
 section in pom.xml for this WAR project.  I have tried removing
 log4j-1.2.16.jar and slf4j-api-1.7.2.jar and see various exceptions in
 karaf.log.

 Bundle-ClassPath.
 ...
 ,WEB-INF/lib/log4j-1.2.16.jar
 ,WEB-INF/lib/slf4j-api-1.7.2.jar
 ,WEB-INF/lib/slf4j-log4j12-1.7.2.jar
 ...
 /Bundle-ClassPath

 Now I have finally resorted to including a log4j.xml file in the root of
 the
 WAR so that log4j will find it in the classpath.  Now the WARN logging
 above
 to the karaf console is gone but the logging for the file appender has a
 different format than what is in the karaf.log.

 Here is my current log4j.xml config.  I was thinking about using
 ./data/log/karaf.log and appending to that log instead of a test.log.


appender name=FILE class=org.apache.log4j.RollingFileAppender






  layout class=org.apache.log4j.PatternLayout

  /layout
/appender

 Am I missing something simple here (i.e. making this too complicated as a
 solution)?  Any assistance is appreciated. thx.



 --
 View this message in context:
 http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739.html
 Sent from the Karaf - User mailing list archive at Nabble.com.




-- 

Apache Member
Apache Karaf http://karaf.apache.org/ Committer  PMC
OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer 
Project Lead
blog http://notizblog.nierbeck.de/

Software Architect / Project Manager / Scrum Master

Re: No appenders could be found for logger (log4j related)

[asookazian2]

This works:

   appender name=FILE class=org.apache.log4j.RollingFileAppender
 
 
 
 

 layout class=org.apache.log4j.PatternLayout
   
 /layout  
   /appender

This does *not* work (i.e. no logging of the same above contents in test.log
are visible in the karaf.log; why?)

   appender name=FILE class=org.apache.log4j.RollingFileAppender
 
 
 
 

 layout class=org.apache.log4j.PatternLayout
   
 /layout  
   /appender



--
View this message in context: 
http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739p4034742.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: No appenders could be found for logger (log4j related)

[asookazian2]

Achim, thx for reply!  So I need to use Import-Package only instead of
Bundle-Classpath?

And if yes, which packages do I need to import specifically?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739p4034743.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: No appenders could be found for logger (log4j related)

[asookazian2]

Ok so I removed the three JARs (one log4j and two slf4j) from the
Bundle-ClassPath section and added the following to the package-import
section:

Import-Package
...
,org.apache.log4j
,org.slf4j
...
/Import-Package

Now I am not seeing the WARN in the console during karaf startup, but I am
seeing the following exception in the log.  Please advise how to resolve. 
Do I need to add log4j back to the bundle-classpath?  thx.

20140813 10:01:03.662 [WARN ] FelixStartLevel |
138:org.ops4j.pax.web.pax-web-extender-war |
org.ops4j.pax.web.extender.war.internal.Activator | Error while destroying
extension for bundle RelationManager-OSGi [242]
java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
org/apache/log4j/LogManager
at 
java.util.concurrent.FutureTask.report(FutureTask.java:122)[:1.7.0_51]
at java.util.concurrent.FutureTask.get(FutureTask.java:188)[:1.7.0_51]
at
org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.destroyExtension(AbstractExtender.java:309)[138:org.ops4j.pax.web.pax-web-extender-war:3.1.0]
at
org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.bundleChanged(AbstractExtender.java:188)[138:org.ops4j.pax.web.pax-web-extender-war:3.1.0]
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4403)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.Felix.stopBundle(Felix.java:2520)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1309)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)[org.apache.felix.framework-4.2.1.jar:]
at java.lang.Thread.run(Thread.java:744)[:1.7.0_51]
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/LogManager
at
org.springframework.util.Log4jConfigurer.shutdownLogging(Log4jConfigurer.java:117)
at
org.springframework.web.util.Log4jWebConfigurer.shutdownLogging(Log4jWebConfigurer.java:170)
at
org.springframework.web.util.Log4jConfigListener.contextDestroyed(Log4jConfigListener.java:51)
at
org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:823)
at
org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:160)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doStop(HttpServiceContext.java:229)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
at
org.ops4j.pax.web.service.jetty.internal.JettyServerImpl$1.stop(JettyServerImpl.java:202)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted.begin(HttpServiceStarted.java:1018)
at
org.ops4j.pax.web.service.internal.HttpServiceProxy.begin(HttpServiceProxy.java:417)
at
org.ops4j.pax.web.extender.war.internal.UnregisterWebAppVisitorWC.visit(UnregisterWebAppVisitorWC.java:82)
at
org.ops4j.pax.web.extender.war.internal.model.WebApp.accept(WebApp.java:641)
at
org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.unregister(WebAppPublisher.java:264)
at
org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.removedService(WebAppPublisher.java:224)
at
org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.removedService(WebAppPublisher.java:135)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)[karaf-org.osgi.core.jar:]
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)[karaf-org.osgi.core.jar:]
at
org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)[karaf-org.osgi.core.jar:]
at
org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:375)[karaf-org.osgi.core.jar:]
at
org.ops4j.pax.web.extender.war.internal.WebAppPublisher.unpublish(WebAppPublisher.java:127)
at
org.ops4j.pax.web.extender.war.internal.WebObserver.undeploy(WebObserver.java:247)
at
org.ops4j.pax.web.extender.war.internal.WebObserver$1.doDestroy(WebObserver.java:185)
at
org.ops4j.pax.web.extender.war.internal.extender.SimpleExtension.destroy(SimpleExtension.java:70)
at
org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender$2.run(AbstractExtender.java:288)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_51

Re: No appenders could be found for logger (log4j related)

[asookazian2]

So I added back the following to the Bundle-ClassPath section:

,WEB-INF/lib/log4j-1.2.16.jar

and still getting this exception on karaf startup.  I still have the import
for org.apache.log4j in the Import-Package section so not sure what else
to try at this point

Caused by: java.lang.ClassNotFoundException: org.apache.log4j.LogManager not
found by org.ops4j.pax.logging.pax-logging-api [7]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)[org.apache.felix.framework-4.2.1.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)[:1.7.0_51]
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1374)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1553)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1484)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)[org.apache.felix.framework-4.2.1.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)[:1.7.0_51]
... 36 more



--
View this message in context: 
http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739p4034747.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: No appenders could be found for logger (log4j related)

[bane73]

Not really the most correct answer, but try modifying your export section to
export everything.
That SHOULD work, I believe, because your project is using that JAR (thus,
it's contained inside of it) but you are not telling OSGI that you want to
use it and so it is blocking it from your JAR's classpath.  

IOW, in your POM right below the Bundle-ClassPath section you should have
a Export-Package section.  Delete everything and replace with a wildcard:

ie: Export-Package*/Export-Package

That should do the trick.  If it does, don't settle for that though.  The
correct answer is, I think, to install org.apache.log4j either as it's own
bundle or as a part of a dependency-bundle.  I'm still pretty new to OSGI,
though, so I could be wrong.





--
View this message in context: 
http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739p4034748.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: No appenders could be found for logger (log4j related)

[Achim Nierbeck]

First of all, if you want to have a working logging with Karaf, use the
logging provided by it.
Karaf uses Pax Logging which supports a wide range of logging frameworks.
So don't embed log4j in your bundles. It's not needed and just doesn't work
that way!

You also should check the way you do your logging. Either you have a custom
appender which needs to be registered in a different way.
Or you doing something else strange.
Cause usually a logging like the following is sufficient:

LoggerFactory.getLogger(LoggingClass.class);
log.error(this is my error message with content {}, content); //slf4j
style logging

For using a custom appender (or something similar), you either might check
the mailing-list or take a look at [1].

regards, Achim

[1] -
http://notizblog.nierbeck.de/2011/08/adding-custom-log-appender-to-pax-logging/




2014-08-13 20:35 GMT+02:00 bane73 bran...@thegreshams.net:

 Not really the most correct answer, but try modifying your export section
 to
 export everything.
 That SHOULD work, I believe, because your project is using that JAR (thus,
 it's contained inside of it) but you are not telling OSGI that you want to
 use it and so it is blocking it from your JAR's classpath.

 IOW, in your POM right below the Bundle-ClassPath section you should have
 a Export-Package section.  Delete everything and replace with a wildcard:

 ie: Export-Package*/Export-Package

 That should do the trick.  If it does, don't settle for that though.  The
 correct answer is, I think, to install org.apache.log4j either as it's own
 bundle or as a part of a dependency-bundle.  I'm still pretty new to
 OSGI,
 though, so I could be wrong.





 --
 View this message in context:
 http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739p4034748.html
 Sent from the Karaf - User mailing list archive at Nabble.com.




-- 

Apache Member
Apache Karaf http://karaf.apache.org/ Committer  PMC
OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer 
Project Lead
blog http://notizblog.nierbeck.de/

Software Architect / Project Manager / Scrum Master

Re: No appenders could be found for logger (log4j related)

[asookazian2]

Thanks for the tip. I tried this and it did not work.

Still seeing exception in the karaf.log:

Caused by: java.lang.ClassNotFoundException: org.apache.log4j.LogManager not
found by org.ops4j.pax.logging.pax-logging-api [7]

I will try to research the response that Achim gave.  thx guys.


bane73 wrote
 Not really the most correct answer, but try modifying your export section
 to export everything.
 That SHOULD work, I believe, because your project is using that JAR (thus,
 it's contained inside of it) but you are not telling OSGI that you want to
 use it and so it is blocking it from your JAR's classpath.  
 
 IOW, in your POM right below the 
 Bundle-ClassPath
  section you should have a 
 Export-Package
  section.  Delete everything and replace with a wildcard:
 
 ie: 
 Export-Package
 *
 /Export-Package
 That should do the trick.  If it does, don't settle for that though.  The
 correct answer is, I think, to install org.apache.log4j either as it's own
 bundle or as a part of a dependency-bundle.  I'm still pretty new to
 OSGI, though, so I could be wrong.





--
View this message in context: 
http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739p4034752.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: No appenders could be found for logger (log4j related)

[Jean-Baptiste Onofré]

Hi guys,

sorry I was out for a rugby game ;)

Pax Logging wraps log4j, it doesn't import the whole log4j api.
Some part of the log4j API is not included because all doesn't make 
sense in OSGi.
It's the case for org.apache.log4j.LogManager: it's part of log4j but 
it's not included in pax-logging (api or service).


In the latest pax-logging release, I included a couple of Log4j and 
SLf4j new classes, but not this one as it's not really usefull in OSGi 
(due to the Logging service).


So, what's your usage of LogManager ? I'm pretty sure you can avoid to 
use it.


Regards
JB

On 08/13/2014 10:21 PM, asookazian2 wrote:

Thanks for the tip. I tried this and it did not work.

Still seeing exception in the karaf.log:

Caused by: java.lang.ClassNotFoundException: org.apache.log4j.LogManager not
found by org.ops4j.pax.logging.pax-logging-api [7]

I will try to research the response that Achim gave.  thx guys.


bane73 wrote

Not really the most correct answer, but try modifying your export section
to export everything.
That SHOULD work, I believe, because your project is using that JAR (thus,
it's contained inside of it) but you are not telling OSGI that you want to
use it and so it is blocking it from your JAR's classpath.

IOW, in your POM right below the
Bundle-ClassPath
  section you should have a
Export-Package
  section.  Delete everything and replace with a wildcard:

ie:
Export-Package
*
/Export-Package
That should do the trick.  If it does, don't settle for that though.  The
correct answer is, I think, to install org.apache.log4j either as it's own
bundle or as a part of a dependency-bundle.  I'm still pretty new to
OSGI, though, so I could be wrong.






--
View this message in context: 
http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739p4034752.html
Sent from the Karaf - User mailing list archive at Nabble.com.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: No appenders could be found for logger (log4j related)

[asookazian2]

In the web.xml:

listener
   
listener-classorg.springframework.web.util.Log4jConfigListener/listener-class
/listener

Should we be using a different listener?



--
View this message in context: 
http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739p4034755.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: No appenders could be found for logger (log4j related)

[asookazian2]

Rugby, man that's tough!  hope you're ok. ;)

http://grepcode.com/file/repo1.maven.org/maven2/org.springframework/spring-core/2.5.4/org/springframework/util/Log4jConfigurer.java

This class is using LogManager...


jbonofre wrote
 Hi guys,
 
 sorry I was out for a rugby game ;)
 
 Pax Logging wraps log4j, it doesn't import the whole log4j api.
 Some part of the log4j API is not included because all doesn't make 
 sense in OSGi.
 It's the case for org.apache.log4j.LogManager: it's part of log4j but 
 it's not included in pax-logging (api or service).
 
 In the latest pax-logging release, I included a couple of Log4j and 
 SLf4j new classes, but not this one as it's not really usefull in OSGi 
 (due to the Logging service).
 
 So, what's your usage of LogManager ? I'm pretty sure you can avoid to 
 use it.
 
 Regards
 JB
 
 On 08/13/2014 10:21 PM, asookazian2 wrote:
 Thanks for the tip. I tried this and it did not work.

 Still seeing exception in the karaf.log:

 Caused by: java.lang.ClassNotFoundException: org.apache.log4j.LogManager
 not
 found by org.ops4j.pax.logging.pax-logging-api [7]

 I will try to research the response that Achim gave.  thx guys.


 bane73 wrote
 Not really the most correct answer, but try modifying your export
 section
 to export everything.
 That SHOULD work, I believe, because your project is using that JAR
 (thus,
 it's contained inside of it) but you are not telling OSGI that you want
 to
 use it and so it is blocking it from your JAR's classpath.

 IOW, in your POM right below the
 
 Bundle-ClassPath
   section you should have a
 
 Export-Package
   section.  Delete everything and replace with a wildcard:

 ie:
 
 Export-Package
 *
 
 /Export-Package
 That should do the trick.  If it does, don't settle for that though. 
 The
 correct answer is, I think, to install org.apache.log4j either as it's
 own
 bundle or as a part of a dependency-bundle.  I'm still pretty new to
 OSGI, though, so I could be wrong.





 --
 View this message in context:
 http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739p4034752.html
 Sent from the Karaf - User mailing list archive at Nabble.com.

 
 -- 
 Jean-Baptiste Onofré

 jbonofre@

 http://blog.nanthrax.net
 Talend - http://www.talend.com





--
View this message in context: 
http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739p4034756.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: No appenders could be found for logger (log4j related)

[asookazian2]

I commented out the below listener block in the web.xml.  Now it seems to be
behaving better (no exceptions) but I'm not sure what side-effect it may
have to remove that...


asookazian2 wrote
 In the web.xml:
 listener
 
 listener-class
 org.springframework.web.util.Log4jConfigListener
 /listener-class
 
 /listener
 Should we be using a different listener?





--
View this message in context: 
http://karaf.922171.n3.nabble.com/No-appenders-could-be-found-for-logger-log4j-related-tp4034739p4034757.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: NoClassDefFoundError: org/apache/log4j/Layout

[Achim Nierbeck]

Well,

Pax Logging does provide a couple of different APIs for logging:
log4j, slf4j commons-logging, etc..

So actually it's a service that hides a lot of details from you.
As it is using log4j as the underlying logging infrastructure you most
likely are tempted to use a lot of it,
though those internal classes aren't available.
Take a look at the pax-loggin-api bundle and it's exports there you'll find
all packages available to you for usage.
If you want to have a custom Logger, you'll need to add it to the service
bundle as described in the various samples given by me and JB.

regards, Achim



2014-06-25 19:02 GMT+02:00 loky jflebesc...@gmail.com:

 Thanks jbonofre and Achim  for helping me  :)


 jbonofre wrote
  latest section: Custom appenders.
  jbonofre   Pax Logging provides log4j 1.2.15.

 Indeed ! I have plugged it with the 1.2.15 but I still have the problem.
 I have checked the latest section of
 http://karaf.apache.org/manual/latest/users-guide/log.html but have not
 really find my answer (or perhaps I just mist it)


 Achim Nierbeck wrote
  So you are trying to build a custom Logger, is that right?


 Yes, we are using Log4j to produce a log file by process so we have write a
 code which used Log4j ( and works on eclipse and on previous version).

 I have identified more precisely what is wrong. With 2 simples use cases :

 1/ If I do :

 import org.apache.log4j.*;

 public void Log(String logname) {
 Logger filelogger = Logger.getLogger(logname);
 filelogger.info(HELLO);
 }

 == Everything is fine

 2/ If I do :

 public void Log(String logname) {
 Logger filelogger = Logger.getLogger(logname);
 filelogger.info(HELLO);
 filelogger.removeAllAppenders();
 }

 == Aoutch :)
 Caused by: java.lang.NoSuchMethodError:
 org.apache.log4j.Logger.removeAllAppenders()V
   at

 com.ericsson.mediation.core.bean.LoggerWrapper.Log(LoggerWrapper.java:78)[265:MEDIATION-SI800-Core:1.0.0]

 I got the felling that in the karaf context, the org.apache.log4j.Logger is
 not the real one and indeed this is a lot of Logger class declared
 (via a find-class Logger)


 I would like to know if there is a way to tell to
 org.ops4j.pax.logging.pax-logging-XXX to use the  real  one ?

 Thanks for your help :)

 JF



 --
 View this message in context:
 http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033784.html
 Sent from the Karaf - User mailing list archive at Nabble.com.




-- 

Apache Member
Apache Karaf http://karaf.apache.org/ Committer  PMC
OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer 
Project Lead
blog http://notizblog.nierbeck.de/

Software Architect / Project Manager / Scrum Master

Re: NoClassDefFoundError: org/apache/log4j/Layout

[loky]

Thanks Achim !

I am a bit lost in all thanks...

Karaf use pax-loggin-api which declare org.apache.log4j.Logger which is
more an fork/implementation /rewriting is it write ?

I have the feeling that I should investigate more with pax-loggin-api .

I have removed my log4 dependancy and replace it with pax-loggin-api
and pax-loggin-serice
dependancy and indeed there are no
removeAllAppenders method in it.





2014-06-26 10:49 GMT+02:00 Achim Nierbeck [via Karaf] 
ml-node+s922171n4033807...@n3.nabble.com:

 Well,

 Pax Logging does provide a couple of different APIs for logging:
 log4j, slf4j commons-logging, etc..

 So actually it's a service that hides a lot of details from you.
 As it is using log4j as the underlying logging infrastructure you most
 likely are tempted to use a lot of it,
 though those internal classes aren't available.
 Take a look at the pax-loggin-api bundle and it's exports there you'll
 find all packages available to you for usage.
 If you want to have a custom Logger, you'll need to add it to the service
 bundle as described in the various samples given by me and JB.

 regards, Achim



 2014-06-25 19:02 GMT+02:00 loky [hidden email]
 http://user/SendEmail.jtp?type=nodenode=4033807i=0:

 Thanks jbonofre and Achim  for helping me  :)


 jbonofre wrote
  latest section: Custom appenders.
  jbonofre   Pax Logging provides log4j 1.2.15.

 Indeed ! I have plugged it with the 1.2.15 but I still have the problem.
 I have checked the latest section of
 http://karaf.apache.org/manual/latest/users-guide/log.html but have not
 really find my answer (or perhaps I just mist it)


 Achim Nierbeck wrote
  So you are trying to build a custom Logger, is that right?


 Yes, we are using Log4j to produce a log file by process so we have write
 a
 code which used Log4j ( and works on eclipse and on previous version).

 I have identified more precisely what is wrong. With 2 simples use cases :

 1/ If I do :

 import org.apache.log4j.*;

 public void Log(String logname) {
 Logger filelogger = Logger.getLogger(logname);
 filelogger.info(HELLO);
 }

 == Everything is fine

 2/ If I do :

 public void Log(String logname) {
 Logger filelogger = Logger.getLogger(logname);
 filelogger.info(HELLO);
 filelogger.removeAllAppenders();
 }

 == Aoutch :)
 Caused by: java.lang.NoSuchMethodError:
 org.apache.log4j.Logger.removeAllAppenders()V
   at

 com.ericsson.mediation.core.bean.LoggerWrapper.Log(LoggerWrapper.java:78)[265:MEDIATION-SI800-Core:1.0.0]

 I got the felling that in the karaf context, the org.apache.log4j.Logger
 is
 not the real one and indeed this is a lot of Logger class declared
 (via a find-class Logger)


 I would like to know if there is a way to tell to
 org.ops4j.pax.logging.pax-logging-XXX to use the  real  one ?

 Thanks for your help :)

 JF



 --
 View this message in context:
 http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033784.html

 Sent from the Karaf - User mailing list archive at Nabble.com.




 --

 Apache Member
 Apache Karaf http://karaf.apache.org/ Committer  PMC
 OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer 
 Project Lead
 blog http://notizblog.nierbeck.de/

 Software Architect / Project Manager / Scrum Master



 --
  If you reply to this email, your message will be added to the discussion
 below:

 http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033807.html
  To unsubscribe from NoClassDefFoundError: org/apache/log4j/Layout, click
 here
 http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4033773code=amZsZWJlc2NvbnRAZ21haWwuY29tfDQwMzM3NzN8LTE2MjgyOTI4OTg=
 .
 NAML
 http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml





--
View this message in context: 
http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033812.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: NoClassDefFoundError: org/apache/log4j/Layout

[Achim Nierbeck]

Yep, that's the only constraint,
practically for standard logging you usually shouldn't care much.

For example if you take only the slf4j API as your logging api, you don't
really care if it is log4j or logback that does the actuall logging for
you.

So basically Pax Logging tries to do the same ;)

regards, Achim



2014-06-26 13:39 GMT+02:00 loky jflebesc...@gmail.com:

 Thanks Achim !

 I am a bit lost in all thanks...

 Karaf use pax-loggin-api which declare org.apache.log4j.Logger which is
 more an fork/implementation /rewriting is it write ?

 I have the feeling that I should investigate more with pax-loggin-api .

 I have removed my log4 dependancy and replace it with pax-loggin-api
 and pax-loggin-serice
 dependancy and indeed there are no
 removeAllAppenders method in it.





 2014-06-26 10:49 GMT+02:00 Achim Nierbeck [via Karaf] 
 ml-node+s922171n4033807...@n3.nabble.com:

  Well,
 
  Pax Logging does provide a couple of different APIs for logging:
  log4j, slf4j commons-logging, etc..
 
  So actually it's a service that hides a lot of details from you.
  As it is using log4j as the underlying logging infrastructure you most
  likely are tempted to use a lot of it,
  though those internal classes aren't available.
  Take a look at the pax-loggin-api bundle and it's exports there you'll
  find all packages available to you for usage.
  If you want to have a custom Logger, you'll need to add it to the service
  bundle as described in the various samples given by me and JB.
 
  regards, Achim
 
 
 
  2014-06-25 19:02 GMT+02:00 loky [hidden email]
  http://user/SendEmail.jtp?type=nodenode=4033807i=0:
 
  Thanks jbonofre and Achim  for helping me  :)
 
 
  jbonofre wrote
   latest section: Custom appenders.
   jbonofre   Pax Logging provides log4j 1.2.15.
 
  Indeed ! I have plugged it with the 1.2.15 but I still have the problem.
  I have checked the latest section of
  http://karaf.apache.org/manual/latest/users-guide/log.html but have not
  really find my answer (or perhaps I just mist it)
 
 
  Achim Nierbeck wrote
   So you are trying to build a custom Logger, is that right?
 
 
  Yes, we are using Log4j to produce a log file by process so we have
 write
  a
  code which used Log4j ( and works on eclipse and on previous version).
 
  I have identified more precisely what is wrong. With 2 simples use
 cases :
 
  1/ If I do :
 
  import org.apache.log4j.*;
 
  public void Log(String logname) {
  Logger filelogger = Logger.getLogger(logname);
  filelogger.info(HELLO);
  }
 
  == Everything is fine
 
  2/ If I do :
 
  public void Log(String logname) {
  Logger filelogger = Logger.getLogger(logname);
  filelogger.info(HELLO);
  filelogger.removeAllAppenders();
  }
 
  == Aoutch :)
  Caused by: java.lang.NoSuchMethodError:
  org.apache.log4j.Logger.removeAllAppenders()V
at
 
 
 com.ericsson.mediation.core.bean.LoggerWrapper.Log(LoggerWrapper.java:78)[265:MEDIATION-SI800-Core:1.0.0]
 
  I got the felling that in the karaf context, the org.apache.log4j.Logger
  is
  not the real one and indeed this is a lot of Logger class declared
  (via a find-class Logger)
 
 
  I would like to know if there is a way to tell to
  org.ops4j.pax.logging.pax-logging-XXX to use the  real  one ?
 
  Thanks for your help :)
 
  JF
 
 
 
  --
  View this message in context:
 
 http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033784.html
 
  Sent from the Karaf - User mailing list archive at Nabble.com.
 
 
 
 
  --
 
  Apache Member
  Apache Karaf http://karaf.apache.org/ Committer  PMC
  OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer
 
  Project Lead
  blog http://notizblog.nierbeck.de/
 
  Software Architect / Project Manager / Scrum Master
 
 
 
  --
   If you reply to this email, your message will be added to the discussion
  below:
 
 
 http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033807.html
   To unsubscribe from NoClassDefFoundError: org/apache/log4j/Layout, click
  here
  
 http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4033773code=amZsZWJlc2NvbnRAZ21haWwuY29tfDQwMzM3NzN8LTE2MjgyOTI4OTg=
 
  .
  NAML
  
 http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
 
 




 --
 View this message in context:
 http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033812.html
 Sent from the Karaf - User

NoClassDefFoundError: org/apache/log4j/Layout

[loky]

Hey ! 

I have a problem with karaf (packaged in fuse esb version 6.1.0) I am in a
camel / spring / maven / jboss fuse / karaf environnement


I have a bundle which use log4j like this : 

   [...]
   import org.apache.log4j.*;
   [...]
   Logger classlogger = Logger.getLogger(LoggerWrapper);


In dev it works fine but when I run the bundle in the ESB, I have the error
: 

 [...]
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Layout
at
com.ericsson.mediation.core.bean.CoreLogger.log(CoreLogger.java:90)[265:MEDIATION-SI800-Core:1.0.0]
[...]
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Layout not
found by org.ops4j.pax.logging.pax-logging-api [4]

I am in migration from jboss fuse esb 6.0.0 to 6.1.0 , with the previous
version my bundle works fine but I have bundled and installed and OSGI
version of log4j .

I have found this topic :
http://mail-archives.apache.org/mod_mbox/karaf-user/201309.mbox/%3c10791_1379436469_523887b5_10791_2213_1_c4e3c19cd10aa241a4a01199e95bac4102cfbe2...@thsonea01cms05p.one.grp%3E
 

Which talk about exactly the same problem but with no clear answer ( for me
:) 

By the way it works when I use :

[...]
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
[...]
private Logger LOG = LoggerFactory.getLogger(ROUTE.class);

Any help would be really appreciated :) I deal with this problem since
yesterday ... 

Thanks !

JF 




--
View this message in context: 
http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: NoClassDefFoundError: org/apache/log4j/Layout

[loky]

I have exclude log4j dependancy in my maven project and insert
org.ops4j.pax.logging reference.

dependency
groupIdorg.ops4j.pax.logging/groupId
artifactIdpax-logging-api/artifactId
version1.7.2/version
/dependency

dependency
groupIdorg.ops4j.pax.logging/groupId
artifactIdpax-logging-service/artifactId
version1.7.2/version
/dependency


I see that the org.apache.log4j.Logger is not the same than the class in
log4j dependancy ( missing removeAllAppenders / missing setLevel / ... )
that my project used.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033776.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: NoClassDefFoundError: org/apache/log4j/Layout

[loky]

I have try to find a workaround with log4J, but nothing works, any idea ? 



--
View this message in context: 
http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033778.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: NoClassDefFoundError: org/apache/log4j/Layout

[Achim Nierbeck]

So you are trying to build a custom Logger, is that right?

Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Layout
 at
 com.ericsson.mediation.core.bean.CoreLogger.log(CoreLogger.java:90)[265:
 MEDIATION-SI800-Core:1.0.0]


If so you'll need to add this Logger by adding it to the pax-loggin bundle.
It is the same as adding a custom appender to it. The description of it can
be found at [1]

regards, Achim

[1]  -
http://notizblog.nierbeck.de/2011/08/adding-custom-log-appender-to-pax-logging/




2014-06-25 15:52 GMT+02:00 loky jflebesc...@gmail.com:

 I have try to find a workaround with log4J, but nothing works, any idea ?



 --
 View this message in context:
 http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033778.html
 Sent from the Karaf - User mailing list archive at Nabble.com.




-- 

Apache Member
Apache Karaf http://karaf.apache.org/ Committer  PMC
OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer 
Project Lead
blog http://notizblog.nierbeck.de/

Software Architect / Project Manager / Scrum Master

Re: NoClassDefFoundError: org/apache/log4j/Layout

[Jean-Baptiste Onofré]

Hi,

Pax Logging provides log4j 1.2.15.

I bet that you use log4j 1.2.17.
So, your project should use the 1.2.15 log4j dependency and Import-Package.

Regards
JB

On 06/25/2014 02:12 PM, loky wrote:

I have exclude log4j dependancy in my maven project and insert
org.ops4j.pax.logging reference.

dependency
groupIdorg.ops4j.pax.logging/groupId
artifactIdpax-logging-api/artifactId
version1.7.2/version
/dependency

dependency
groupIdorg.ops4j.pax.logging/groupId
artifactIdpax-logging-service/artifactId
version1.7.2/version
/dependency


I see that the org.apache.log4j.Logger is not the same than the class in
log4j dependancy ( missing removeAllAppenders / missing setLevel / ... )
that my project used.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033776.html
Sent from the Karaf - User mailing list archive at Nabble.com.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: NoClassDefFoundError: org/apache/log4j/Layout

[Jean-Baptiste Onofré]

http://karaf.apache.org/manual/latest/users-guide/log.html

latest section: Custom appenders.

Regards
JB

On 06/25/2014 03:57 PM, Achim Nierbeck wrote:

So you are trying to build a custom Logger, is that right?

Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Layout
 at

com.ericsson.mediation.core.bean.CoreLogger.log(CoreLogger.java:90)[265:MEDIATION-SI800-Core:1.0.0]


If so you'll need to add this Logger by adding it to the pax-loggin bundle.
It is the same as adding a custom appender to it. The description of it
can be found at [1]

regards, Achim

[1]  -
http://notizblog.nierbeck.de/2011/08/adding-custom-log-appender-to-pax-logging/




2014-06-25 15:52 GMT+02:00 loky jflebesc...@gmail.com
mailto:jflebesc...@gmail.com:

I have try to find a workaround with log4J, but nothing works, any
idea ?



--
View this message in context:

http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033778.html
Sent from the Karaf - User mailing list archive at Nabble.com.




--

Apache Member
Apache Karaf http://karaf.apache.org/ Committer  PMC
OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer
 Project Lead
blog http://notizblog.nierbeck.de/

Software Architect / Project Manager / Scrum Master



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: NoClassDefFoundError: org/apache/log4j/Layout

[loky]

Thanks jbonofre and Achim  for helping me  :) 


jbonofre wrote
 latest section: Custom appenders.
 jbonofre   Pax Logging provides log4j 1.2.15.

Indeed ! I have plugged it with the 1.2.15 but I still have the problem.
I have checked the latest section of 
http://karaf.apache.org/manual/latest/users-guide/log.html but have not
really find my answer (or perhaps I just mist it)


Achim Nierbeck wrote
 So you are trying to build a custom Logger, is that right?


Yes, we are using Log4j to produce a log file by process so we have write a
code which used Log4j ( and works on eclipse and on previous version). 

I have identified more precisely what is wrong. With 2 simples use cases :

1/ If I do : 

import org.apache.log4j.*;

public void Log(String logname) {
Logger filelogger = Logger.getLogger(logname);
filelogger.info(HELLO);
}

== Everything is fine 

2/ If I do : 

public void Log(String logname) {
Logger filelogger = Logger.getLogger(logname);
filelogger.info(HELLO);
filelogger.removeAllAppenders(); 
}

== Aoutch :) 
Caused by: java.lang.NoSuchMethodError:
org.apache.log4j.Logger.removeAllAppenders()V
  at
com.ericsson.mediation.core.bean.LoggerWrapper.Log(LoggerWrapper.java:78)[265:MEDIATION-SI800-Core:1.0.0]

I got the felling that in the karaf context, the org.apache.log4j.Logger is
not the real one and indeed this is a lot of Logger class declared 
(via a find-class Logger)


I would like to know if there is a way to tell to
org.ops4j.pax.logging.pax-logging-XXX to use the  real  one ?

Thanks for your help :) 

JF



--
View this message in context: 
http://karaf.922171.n3.nabble.com/NoClassDefFoundError-org-apache-log4j-Layout-tp4033773p4033784.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Log4J v2

[Andreas Pieber]

Hey,

The question would rather be:

Does pax-logging support log4jv2 and AFAIK the answer is no. The question
would be: how difficult can it be to add log4j v2 support to pax-logging :-)

Kind regards,
Andreas


On Thu, Jun 13, 2013 at 3:50 PM, CLEMENT Jean-Philippe 
jean-philippe.clem...@fr.thalesgroup.com wrote:

 Dear Karaf Team,

 I would like to know if Karaf (v3) supports Log4J v2?

 Cheers,
 JP

 [@@ OPEN @@]

RE: Log4J v2

[CLEMENT Jean-Philippe]

Thanks for the info.

Is PAX logging part of Felix ?

JP

[@@ OPEN @@]

De : Andreas Pieber [mailto:anpie...@gmail.com]
Envoyé : jeudi 13 juin 2013 15:56
À : Apache Karaf
Objet : Re: Log4J v2

Hey,

The question would rather be:

Does pax-logging support log4jv2 and AFAIK the answer is no. The question would 
be: how difficult can it be to add log4j v2 support to pax-logging :-)

Kind regards,
Andreas

On Thu, Jun 13, 2013 at 3:50 PM, CLEMENT Jean-Philippe 
jean-philippe.clem...@fr.thalesgroup.commailto:jean-philippe.clem...@fr.thalesgroup.com
 wrote:
Dear Karaf Team,

I would like to know if Karaf (v3) supports Log4J v2?

Cheers,
JP

[@@ OPEN @@]

Log4J v2

[CLEMENT Jean-Philippe]

Dear Karaf Team,

I would like to know if Karaf (v3) supports Log4J v2?

Cheers,
JP

[@@ OPEN @@]

Re: Log4J v2

[Achim Nierbeck]

Hi,

no it's not.
https://ops4j1.jira.com/wiki/display/paxlogging/Pax+Logging

regards, Achim


2013/6/13 CLEMENT Jean-Philippe jean-philippe.clem...@fr.thalesgroup.com

 Thanks for the info.

 ** **

 Is PAX logging part of Felix ?

 ** **

 JP

 ** **

 [@@ OPEN @@]

 ** **

 *De :* Andreas Pieber [mailto:anpie...@gmail.com]
 *Envoyé :* jeudi 13 juin 2013 15:56
 *À :* Apache Karaf
 *Objet :* Re: Log4J v2

 ** **

 Hey,

 ** **

 The question would rather be:

 ** **

 Does pax-logging support log4jv2 and AFAIK the answer is no. The question
 would be: how difficult can it be to add log4j v2 support to pax-logging :-)
 

 ** **

 Kind regards,

 Andreas

 ** **

 On Thu, Jun 13, 2013 at 3:50 PM, CLEMENT Jean-Philippe 
 jean-philippe.clem...@fr.thalesgroup.com wrote:

 Dear Karaf Team,

 I would like to know if Karaf (v3) supports Log4J v2?

 Cheers,
 JP

 [@@ OPEN @@]


 

 ** **




-- 

Apache Karaf http://karaf.apache.org/ Committer  PMC
OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer 
Project Lead
OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home
Commiter  Project Lead
blog http://notizblog.nierbeck.de/

Re: Integrate Log4j Nagios Appender into Karaf (SNMP)

[Gert Vanthienen]

L.S.,


FWIW, we also have a JMS appender implementation for Pax Logging
available in Apache ServiceMix that can log messages in Logstash
format.  Logstash in turn is capable of sending passive check results
to Nagios based on information it extracts from that logging.


Regards,

Gert


On Thu, Mar 21, 2013 at 11:47 PM, Jean-Baptiste Onofré j...@nanthrax.net 
wrote:
 Hi,

 you can take a look on that:

 http://blog.nanthrax.net/2012/12/create-custom-log4j-appender-for-karaf-and-pax-logging/

 it may help.

 Regards
 JB


 On 03/21/2013 10:43 AM, a_bouchama wrote:

 Hello,

 We want to monitor all logging messages of karaf, and push it to nagios
 (via
 an SNMP).

 Do you have any idea in order to achieve this goal ? I have found this
 blog
 

 http://tmielke.blogspot.fr/2012/10/integrate-log4j-nagios-appender-into.html

 http://tmielke.blogspot.fr/2012/10/integrate-log4j-nagios-appender-into.html
 , whish's interessent but the push of logging messages is done via NSCA
 Server.

 Thanks in advance

 Regards,



 --
 View this message in context:
 http://karaf.922171.n3.nabble.com/Integrate-Log4j-Nagios-Appender-into-Karaf-SNMP-tp4028271.html
 Sent from the Karaf - User mailing list archive at Nabble.com.


 --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com

Re: Integrate Log4j Nagios Appender into Karaf (SNMP)

[Jean-Baptiste Onofré]

Hi,

you can take a look on that:

http://blog.nanthrax.net/2012/12/create-custom-log4j-appender-for-karaf-and-pax-logging/

it may help.

Regards
JB

On 03/21/2013 10:43 AM, a_bouchama wrote:

Hello,

We want to monitor all logging messages of karaf, and push it to nagios (via
an SNMP).

Do you have any idea in order to achieve this goal ? I have found this blog

http://tmielke.blogspot.fr/2012/10/integrate-log4j-nagios-appender-into.html
http://tmielke.blogspot.fr/2012/10/integrate-log4j-nagios-appender-into.html
, whish's interessent but the push of logging messages is done via NSCA
Server.

Thanks in advance

Regards,



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Integrate-Log4j-Nagios-Appender-into-Karaf-SNMP-tp4028271.html
Sent from the Karaf - User mailing list archive at Nabble.com.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: log4j

[Guillaume Nodet]

That's really the best thing to do in karaf, as the log configuration is
handled in an osgi way, so no code should try to directly configure the
logging framework.

On Fri, May 4, 2012 at 1:01 PM, maaruks maris.orbid...@gmail.com wrote:


 Achim Nierbeck wrote
 
  I'm not sure what you are trying to do, but log4j as slf4j and a
  couple more logging framworks are supported by Karaf.
 

 I am migrating some code to karaf.It turns out Pax Logging doesn't
 allow
 to access all log4j classes.
 I removed code that is trying to access Appender.  Problem solved.


 --
 View this message in context:
 http://karaf.922171.n3.nabble.com/log4j-tp3958839p3961902.html
 Sent from the Karaf - User mailing list archive at Nabble.com.




-- 

Guillaume Nodet

Blog: http://gnodet.blogspot.com/

FuseSource, Integration everywhere
http://fusesource.com

log4j

[maaruks]

Is it possible to use log4j in karaf ?

I have log4j classes in my bundle but I cant access them:

try {
Class? aClass = Class.forName(org.apache.log4j.Appender);
} catch (ClassNotFoundException e) {
throw new RuntimeException(e);
}



java.lang.RuntimeException: java.lang.ClassNotFoundException:
org.apache.log4j.Appender not found by org.ops4j.pax.logging.pax-logging-api
[4]
...
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Appender not
found by org.ops4j.pax.logging.pax-logging-api [4]
at
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:787)
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_26]
at
org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:645)
at
org.apache.felix.framework.resolver.WireImpl.getClass(WireImpl.java:99)
at
org.apache.felix.framework.ModuleImpl.searchImports(ModuleImpl.java:1390)
at
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:722)
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_26]
at java.lang.Class.forName0(Native Method)[:1.6.0_26]
at java.lang.Class.forName(Class.java:169)[:1.6.0_26]


--
View this message in context: 
http://karaf.922171.n3.nabble.com/log4j-tp3958839.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: log4j

[Achim Nierbeck]

I'm not sure what you are trying to do, but log4j as slf4j and a
couple more logging framworks are supported by Karaf.
We use Pax Logging for this, log4j is even the underlying
implementation for logging.
If you want to use your own appenders you need to take special care for this.

Regards, Achim

2012/5/3 maaruks maris.orbid...@gmail.com:
 Is it possible to use log4j in karaf ?

 I have log4j classes in my bundle but I cant access them:

        try {
            Class? aClass = Class.forName(org.apache.log4j.Appender);
        } catch (ClassNotFoundException e) {
            throw new RuntimeException(e);
        }



 java.lang.RuntimeException: java.lang.ClassNotFoundException:
 org.apache.log4j.Appender not found by org.ops4j.pax.logging.pax-logging-api
 [4]
 ...
 Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Appender not
 found by org.ops4j.pax.logging.pax-logging-api [4]
    at
 org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:787)
    at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
    at
 org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_26]
    at
 org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:645)
    at
 org.apache.felix.framework.resolver.WireImpl.getClass(WireImpl.java:99)
    at
 org.apache.felix.framework.ModuleImpl.searchImports(ModuleImpl.java:1390)
    at
 org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:722)
    at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
    at
 org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_26]
    at java.lang.Class.forName0(Native Method)[:1.6.0_26]
    at java.lang.Class.forName(Class.java:169)[:1.6.0_26]


 --
 View this message in context: 
 http://karaf.922171.n3.nabble.com/log4j-tp3958839.html
 Sent from the Karaf - User mailing list archive at Nabble.com.



-- 

Apache Karaf http://karaf.apache.org/ Committer  PMC
OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/
Committer  Project Lead
OPS4J Pax Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home
Commiter  Project Lead
blog http://notizblog.nierbeck.de/

Re: log4j

[Guillaume Nodet]

Custom appenders can be deployed by using fragments attached to the
pax-logging-service bundle fwiw.

On Thu, May 3, 2012 at 1:21 PM, Achim Nierbeck bcanh...@googlemail.comwrote:

 I'm not sure what you are trying to do, but log4j as slf4j and a
 couple more logging framworks are supported by Karaf.
 We use Pax Logging for this, log4j is even the underlying
 implementation for logging.
 If you want to use your own appenders you need to take special care for
 this.

 Regards, Achim

 2012/5/3 maaruks maris.orbid...@gmail.com:
  Is it possible to use log4j in karaf ?
 
  I have log4j classes in my bundle but I cant access them:
 
 try {
 Class? aClass = Class.forName(org.apache.log4j.Appender);
 } catch (ClassNotFoundException e) {
 throw new RuntimeException(e);
 }
 
 
 
  java.lang.RuntimeException: java.lang.ClassNotFoundException:
  org.apache.log4j.Appender not found by
 org.ops4j.pax.logging.pax-logging-api
  [4]
  ...
  Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Appender
 not
  found by org.ops4j.pax.logging.pax-logging-api [4]
 at
 
 org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:787)
 at
 org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
 at
 
 org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_26]
 at
 
 org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:645)
 at
  org.apache.felix.framework.resolver.WireImpl.getClass(WireImpl.java:99)
 at
  org.apache.felix.framework.ModuleImpl.searchImports(ModuleImpl.java:1390)
 at
 
 org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:722)
 at
 org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
 at
 
 org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_26]
 at java.lang.Class.forName0(Native Method)[:1.6.0_26]
 at java.lang.Class.forName(Class.java:169)[:1.6.0_26]
 
 
  --
  View this message in context:
 http://karaf.922171.n3.nabble.com/log4j-tp3958839.html
  Sent from the Karaf - User mailing list archive at Nabble.com.



 --

 Apache Karaf http://karaf.apache.org/ Committer  PMC
 OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/
 Committer  Project Lead
 OPS4J Pax Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home
 Commiter  Project Lead
 blog http://notizblog.nierbeck.de/




-- 

Guillaume Nodet

Blog: http://gnodet.blogspot.com/

FuseSource, Integration everywhere
http://fusesource.com

Re: Logging using log4j filters

[Bengt Rodehav]

FYI Guillaume,

I continued this discussion on the OPS4J mailing list:

http://www.mail-archive.com/general@lists.ops4j.org/msg12287.html

/Bengt

2012/1/30 Bengt Rodehav be...@rodehav.com

 A moment ago I thought I had solved the problem since I noticed that I had
 written bunde.name:... instead of bundle.name: That would have
 explained everything but unfortunately I still can't get it to work after
 having corrected my spelling.

 Using the org.apache.camel logger won't help me here. Although my example
 uses bundle.name, I intend to use the camelContext MDC in production.
 We have dozens of camel routes that we want to put in different log files
 depending on which camel context we need to debug. Thus the logger (i e the
 package name) is of no help. MDC is needed to get this to work.

 I see your point now that the layout isn't taken into account. Actually I
 had not understood that the string bundle.name:org.apache.camel.camel-core
 had to be found in the log message. I thought it was a special syntax where
 the value before the colon was the name of an MDC key. I now changed the
 layout to the following:

 *log4j.appender.bundle_trace.appender.layout.ConversionPattern=%d{ISO8601}
 | bundle.name:%X{bundle.name} | %-5.5p | %-16.16t | %-32.32c{1} |
 %-32.32C %4L | %m%n*

 but the filter still didn't match. I then changed the string to match to
 something that occurs in a lot of messages (e g Starting to poll) and
 noticed that exactly those lines were logged at TRACE level.

 Thanks for your help Guillaume. I know understand better how log4j filters
 work. I think I will probably create my own filter that tries to match a
 given MDC key to a certain value. This I think could be of value to others
 as well.


 /Bengt

 2012/1/30 Guillaume Nodet gno...@gmail.com

 The StringMatchFilter only apply the matching to the message, not the
 full event, so the layout isn't taken into account.  And I don't think
 any of the camel log message will contain bundle.name:xxx.

 Why don't you attach a specific appender to org.apache.camel logger
 instead ?  Else you'll have to define your own filter.  I guess
 generic filters could be added to pax-logging if they're missing.

 On Mon, Jan 30, 2012 at 12:00, Bengt Rodehav be...@rodehav.com wrote:
  I also tried the following:
 
 
 log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.StringMatchFilter
  log4j.appender.bundle_trace.filter.a.StringToMatch=bunde.name:
 org.apache.camel.camel-core
  log4j.appender.bundle_trace.filter.a.AcceptOnMatch=false
 
  I didn't use a DenyAllFilter in this case. If the StringMatchFilter
 worked,
  I would expect to get trace logfiles for all bundles
  EXCEPT org.apache.camel.camel-core.. But I get trace logfiles for all
  bundles including org.apache.camel.camel-core.
 
  I think this indicates that the problem is the StringMatchFilter and
 not the
  DenyAllFilter...
 
  I have verified that the bundle name is written correctly. Could it be
 some
  escape problems connected to config admin?
 
  /Bengt
 
 
 
 
  2012/1/30 Bengt Rodehav be...@rodehav.com
 
  I tried these four combinations:
 
  # 1
 
 
 log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.StringMatchFilter
 
  log4j.appender.bundle_trace.filter.a.StringToMatch=bunde.name:
 org.apache.camel.camel-core
  log4j.appender.bundle_trace.filter.a.AcceptOnMatch=true
 
 log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.DenyAllFilter
 
  # 2
 
 log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.DenyAllFilter
 
 
 log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.StringMatchFilter
 
  log4j.appender.bundle_trace.filter.a.StringToMatch=bunde.name:
 org.apache.camel.camel-core
  log4j.appender.bundle_trace.filter.a.AcceptOnMatch=true
 
  # 3
 
 log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.DenyAllFilter
 
 
 log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.StringMatchFilter
 
  log4j.appender.bundle_trace.filter.b.StringToMatch=bunde.name:
 org.apache.camel.camel-core
  log4j.appender.bundle_trace.filter.b.AcceptOnMatch=true
 
  # 4
 
 
 log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.StringMatchFilter
 
  log4j.appender.bundle_trace.filter.b.StringToMatch=bunde.name:
 org.apache.camel.camel-core
  log4j.appender.bundle_trace.filter.b.AcceptOnMatch=true
 
 log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.DenyAllFilter
 
  This would check if ordering of the configurations or filter naming
 would
  make a difference. Unfortunately none of the above work.
 
  But as soon as I comment out the DenyAllFilter, trace logfiles appear
 in
  the trace folder. So, either the DenyAllFilter prevents the
  StringMatchFilter from working or the StringMatchFilter never
 matches...
 
  /Bengt
 
 
 
 
 
  2012/1/30 Guillaume Nodet gno...@gmail.com
 
  Looking at the log4j code, it seems the filters are ordered using
  their ids, so in your case accept and deny.
  So I think the order should be ok.  Can you

Logging using log4j filters

[Bengt Rodehav]

I have the following configuration in my org.ops4j.pax.logging.cfg:

*# Per bundle log at INFO level*
*log4j.appender.bundle=org.apache.log4j.sift.MDCSiftingAppender*
*log4j.appender.bundle.key=bundle.name*
*log4j.appender.bundle.default=karaf*
*log4j.appender.bundle.appender=org.apache.log4j.RollingFileAppender*
*log4j.appender.bundle.appender.MaxFileSize=10MB*
*log4j.appender.bundle.appender.MaxBackupIndex=2*
*log4j.appender.bundle.appender.layout=org.apache.log4j.PatternLayout*
*log4j.appender.bundle.appender.layout.ConversionPattern=%d{ISO8601} |
%-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n*
*log4j.appender.bundle.appender.file=${logdir}/bundles/$\\{bundle.name
\\}.log*
*log4j.appender.bundle.appender.append=true*
*log4j.appender.bundle.threshold=INFO*
*
*
*# TRACE level for specific bundle - should normally be disabled*
*log4j.appender.bundle_trace=org.apache.log4j.sift.MDCSiftingAppender*
*log4j.appender.bundle_trace.key=bundle.name*
*log4j.appender.bundle_trace.default=karaf*
*log4j.appender.bundle_trace.appender=org.apache.log4j.RollingFileAppender*
*log4j.appender.bundle_trace.appender.MaxFileSize=20MB*
*log4j.appender.bundle_trace.appender.MaxBackupIndex=1*
*log4j.appender.bundle_trace.appender.layout=org.apache.log4j.PatternLayout*
*log4j.appender.bundle_trace.appender.layout.ConversionPattern=%d{ISO8601}
| %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n*
*log4j.appender.bundle_trace.appender.file=${logdir}/bundles/trace/$\\{
bundle.name\\}.log*
*log4j.appender.bundle_trace.appender.append=true*
*log4j.appender.bundle_trace.threshold=TRACE*
*
log4j.appender.bundle_trace.filter.accept=org.apache.log4j.varia.StringMatchFilter
*
*log4j.appender.bundle_trace.filter.accept.StringToMatch=bunde.name:
org.apache.camel.camel-core*
*log4j.appender.bundle_trace.filter.accept.AcceptOnMatch=false*
*
log4j.appender.bundle_trace.filter.deny=org.apache.log4j.varia.DenyAllFilter
*

The intention is to have bundle specific logs at INFO level but have a
separate TRACE log for a specific bundle. The latter is not enabled by
default but only when debugging.

The problem is that the *DenyAllFilter* seems to take precedence over the *
StringMatchFilter*. I believe that when listed in the order I do, the
bundle with the name *org.apache.camel.camel-core* should be logged at
TRACE level but no other bundles. Could it be that the ordering of filters
are not preserved? I think that native log4j only supports filters when
using XML configuration and I assume that the Karaf filtering support has
been added on top of log4j (or is it in Pax-logging)? Has the ordering of
filters been taken into account?

I've been testing this on Karaf 2.2.0 with Pax logging 1.6.0.

/Bengt

Re: Logging using log4j filters

[Guillaume Nodet]

The filter support has been added in pax-logging.
Have a look at
   
https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/PaxLoggingConfigurator.java

You may very well be right that the order isn't kept, which would
definitely be a bug.

On Mon, Jan 30, 2012 at 10:17, Bengt Rodehav be...@rodehav.com wrote:
 I have the following configuration in my org.ops4j.pax.logging.cfg:

 # Per bundle log at INFO level
 log4j.appender.bundle=org.apache.log4j.sift.MDCSiftingAppender
 log4j.appender.bundle.key=bundle.name
 log4j.appender.bundle.default=karaf
 log4j.appender.bundle.appender=org.apache.log4j.RollingFileAppender
 log4j.appender.bundle.appender.MaxFileSize=10MB
 log4j.appender.bundle.appender.MaxBackupIndex=2
 log4j.appender.bundle.appender.layout=org.apache.log4j.PatternLayout
 log4j.appender.bundle.appender.layout.ConversionPattern=%d{ISO8601} | %-5.5p
 | %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
 log4j.appender.bundle.appender.file=${logdir}/bundles/$\\{bundle.name\\}.log
 log4j.appender.bundle.appender.append=true
 log4j.appender.bundle.threshold=INFO

 # TRACE level for specific bundle - should normally be disabled
 log4j.appender.bundle_trace=org.apache.log4j.sift.MDCSiftingAppender
 log4j.appender.bundle_trace.key=bundle.name
 log4j.appender.bundle_trace.default=karaf
 log4j.appender.bundle_trace.appender=org.apache.log4j.RollingFileAppender
 log4j.appender.bundle_trace.appender.MaxFileSize=20MB
 log4j.appender.bundle_trace.appender.MaxBackupIndex=1
 log4j.appender.bundle_trace.appender.layout=org.apache.log4j.PatternLayout
 log4j.appender.bundle_trace.appender.layout.ConversionPattern=%d{ISO8601} |
 %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
 log4j.appender.bundle_trace.appender.file=${logdir}/bundles/trace/$\\{bundle.name\\}.log
 log4j.appender.bundle_trace.appender.append=true
 log4j.appender.bundle_trace.threshold=TRACE
 log4j.appender.bundle_trace.filter.accept=org.apache.log4j.varia.StringMatchFilter
 log4j.appender.bundle_trace.filter.accept.StringToMatch=bunde.name:org.apache.camel.camel-core
 log4j.appender.bundle_trace.filter.accept.AcceptOnMatch=false
 log4j.appender.bundle_trace.filter.deny=org.apache.log4j.varia.DenyAllFilter

 The intention is to have bundle specific logs at INFO level but have a
 separate TRACE log for a specific bundle. The latter is not enabled by
 default but only when debugging.

 The problem is that the DenyAllFilter seems to take precedence over the
 StringMatchFilter. I believe that when listed in the order I do, the bundle
 with the name org.apache.camel.camel-core should be logged at TRACE level
 but no other bundles. Could it be that the ordering of filters are not
 preserved? I think that native log4j only supports filters when using XML
 configuration and I assume that the Karaf filtering support has been added
 on top of log4j (or is it in Pax-logging)? Has the ordering of filters been
 taken into account?

 I've been testing this on Karaf 2.2.0 with Pax logging 1.6.0.

 /Bengt



-- 

Guillaume Nodet

Blog: http://gnodet.blogspot.com/

FuseSource, Integration everywhere
http://fusesource.com